REST vs RPC
Model your API around resources you manipulate, or around procedures you call — a choice between web-friendly uniformity and tight, efficient method calls.
Two ways to design an API
- REST — model the system as resources (nouns) addressed by URLs, acted on with standard HTTP verbs. “Operate on things.”
- RPC — model the system as procedures (verbs) you call remotely, as if invoking a local function. “Call methods.”
REST
GET /users/123, POST /orders, DELETE /posts/9 — uniform verbs over
resources.
- Wins: uses HTTP natively, so it’s cacheable (GETs), stateless, and works everywhere; a uniform, discoverable interface; loose client–server coupling; great for public APIs and browsers.
- Costs: awkward for actions that aren’t CRUD (“transfer money,” “send”); can be chatty (multiple round trips to assemble data) and over/under-fetch (fixed response shapes).
- Use for: public web APIs, resource-oriented CRUD, broad client compatibility.
RPC
transferMoney(from, to, amount), sendNotification(userId, msg) — call a named
method with arguments.
- Wins: maps directly to actions; can be very efficient (binary protocols like gRPC/Protobuf, HTTP/2 multiplexing, streaming); strong typing and generated client stubs; great for internal service-to-service calls.
- Costs: tighter coupling (clients know method signatures); less HTTP-native (caching/standard tooling harder); binary formats aren’t human-readable; cross-language support varies.
- Use for: internal microservice communication, low-latency/high-throughput, streaming.
The side-by-side
| REST | RPC (e.g. gRPC) | |
|---|---|---|
| Models | Resources (nouns) | Procedures (verbs) |
| Transport | HTTP/1.1, JSON | Often HTTP/2, binary (Protobuf) |
| Caching | Native (GET) | Manual |
| Coupling | Loose | Tighter |
| Best at | Public APIs, CRUD | Internal, high-perf, streaming |
| Discoverability | High | Lower (needs schema) |
(And GraphQL, briefly)
Worth a mention: GraphQL lets clients request exactly the fields they need in one round trip — solving REST’s over/under-fetching for complex, client-driven UIs — at the cost of caching complexity and server-side query cost control.
The interview cue
The common, mature split: “REST (or GraphQL) at the edge for public clients and browsers — cacheable and standard; gRPC between services internally for efficient, strongly-typed, low-latency calls and streaming.” Choosing by who the caller is — external uniformity vs internal performance — is the signal.