REST vs RPC

REST

REST treats a system as a collection of resources. Each resource has its own URL, and the standard HTTP methods act on it:

GET    /products        list the products
POST   /products        create a new product
GET    /products/42     read product 42
PUT    /products/42     replace product 42
DELETE /products/42     delete product 42

The methods have agreed meanings. GET is safe, which means it only reads data. GET, PUT, and DELETE are also idempotent, which means repeating the same request has the same effect as sending it once. So a client can safely retry them after a timeout. POST is not idempotent, so a retry may create a second product.

What REST Gives You

• A uniform interface. Every resource uses the same few methods. Any developer with any HTTP client can call the API.
• Statelessness. Each request carries everything the server needs, so any server can answer any request. The Stateful vs Stateless Architecture lesson explains why this helps scaling.
• Caching by existing infrastructure. Browsers, CDNs, and proxies know that a GET response can often be stored and reused. They can cache it without understanding your application. The Caching lesson covers these layers.
• Easy debugging. Responses are usually readable JSON text. You can test any endpoint with a browser or a command-line tool like curl.

What REST Costs You

• Over-fetching and under-fetching. Each endpoint returns a fixed shape. Over-fetching means the client downloads fields it does not use. Under-fetching means one screen needs data from several resources, so the client makes several round trips.
• Awkward actions. "Send this invoice for approval" is an action, not a thing. Forcing it into a resource can produce strange URLs, like POST /invoices/42/approval-requests.
• No enforced contract. REST is a set of conventions. Tools like OpenAPI can describe an API, but nothing forces the client and server to agree. A breaking change may be found only when a client fails.

RPC and gRPC

With RPC, the client calls a function. A framework packs the arguments, sends them over the network, runs the function on the server, and returns the result.

In modern systems, RPC often means gRPC, an open source RPC framework. Three features define it.

1. A written contract. Every method, argument, and return type is described in a .proto file:

service Catalog {
  rpc GetProduct (GetProductRequest) returns (Product);
}

message GetProductRequest {
  int64 id = 1;
}

message Product {
  int64 id = 1;
  string name = 2;
  int64 price_cents = 3;
}

2. Code generation. Tools generate the client code and the server code from this file. If a team renames a field, code that still uses the old name no longer compiles. The mistake appears when the code is built, not when users are affected.

3. A compact, fast wire format. Messages are encoded as Protocol Buffers, a compact binary format. They travel over HTTP/2, which can carry many calls on one connection at the same time. gRPC also supports streaming, where one call carries a sequence of messages, in either direction.

What gRPC Gives You

• Speed. Binary messages are usually smaller than JSON, and faster to read and write. Reusing connections avoids repeated setup work. This matters most when one user request causes many internal calls.
• Safety. The generated contract prevents many mistakes between the client and the server.
• Streaming. A server can send a stream of results over a single call.
• Natural actions. Calls like ApproveInvoice fit naturally, because they are already functions.

What gRPC Costs You

• Browsers cannot call it directly. gRPC needs features of HTTP/2 that browsers do not expose. A browser needs a translation layer, like gRPC-Web, or a REST API in front.
• Not readable. Binary messages cannot be read by eye, so debugging needs special tools.
• No HTTP caching. Every gRPC call is sent as an HTTP POST. So CDNs and proxies cannot cache the responses.
• Tighter coupling. Both sides are built from the same contract. Changes need coordination between the teams.

The Difference Is Not the Data Format

A common shortcut says that REST is "the JSON one", and gRPC is "the binary one". That shortcut is wrong.

A REST API can return JSON, XML, HTML, or an image. Content negotiation is the HTTP feature that lets a client ask for the format it prefers. And RPC is not always binary. For example, JSON-RPC sends plain JSON text.

Most REST APIs do use JSON, and gRPC does use Protocol Buffers. But that is a common choice, not the real difference. The real difference is what the API names, and what is enforced. REST names resources and relies on conventions. gRPC names procedures and enforces a contract through generated code.

The caching difference follows from this. A REST GET can be answered by a cache on the way to the server. A gRPC call always reaches the server.

Where Each Style Is Usually Used

The two styles are not really competitors. Most large systems use both, in different places.

REST is used at the edge. The callers there are browsers, mobile apps, and outside developers. You do not control those clients, so the universal and cacheable option is the better fit. An API gateway usually receives this traffic.

gRPC is used inside the system. Between your own services, you control both sides. One user request may cause many internal calls, so speed matters. The enforced contract also prevents mistakes between teams.

One more style is worth knowing. GraphQL is a query language where the client lists exactly the fields it wants. It was created to fix over-fetching and under-fetching. Its costs are that normal HTTP caching works less well, and the server must be protected from very expensive queries.

REST vs. gRPC

Choosing Between Them

• A public API, outside developers, or browsers: use REST. You do not control the callers, so universal support and caching matter most.
• Many calls between internal services: use gRPC. You control both sides, and speed and the contract matter.
• Streaming between services: use gRPC, because streaming is built in.
• A mobile screen that needs data from many resources: consider GraphQL, or one endpoint designed for that screen.
• Both needs in one system: use both. REST at the edge and gRPC inside is the usual design, not a compromise.

Using This in an Interview

The expected design is REST at the edge and gRPC inside. What earns credit is the reason. For example: "Services call each other with gRPC, because one request causes eight internal calls. Binary messages over shared HTTP/2 connections reduce that latency. The public API uses REST, because browsers and partners cannot call gRPC directly."

Two follow-up questions are common:

• "Why not use gRPC everywhere?" Browsers need a translation layer to call it, and responses cannot use HTTP caching.
• "Isn't REST just JSON?" No. REST can return XML or other formats. The real difference is resources versus procedures.

Key Takeaways

• REST names resources and uses HTTP methods to act on them. It relies on conventions, not an enforced contract.
• REST gives universal clients, stateless requests, caching by existing infrastructure, and easy debugging.
• RPC is procedure-oriented: the client calls a remote function. gRPC encodes messages in Protocol Buffers, a compact binary format, and sends them over HTTP/2.
• gRPC gives speed, a contract enforced by generated code, and built-in streaming. But browsers cannot call it directly, and it cannot use HTTP caching.
• The data format is not the real difference. The difference is naming resources versus naming procedures.
• Use REST for the public edge, and gRPC for calls between internal services. Most real systems use both.

REST and gRPC answer the same question in different ways: what does a call between two systems look like? The next lesson, Synchronous vs Asynchronous Communication, looks at a different question: whether the caller should wait for the answer.

Practice Questions

Try each question first, then open the answer.

1. A company is building a public API for outside developers, who will call it from browsers, mobile apps, and scripts. Should it use REST or gRPC?

<details> <summary>Show answer</summary>

REST. The company does not control the callers, and REST works with any HTTP client, including browsers. GET responses can also be cached by browsers and CDNs. gRPC would need a translation layer for browsers, and developers would need special tools to read the messages.

</details>

2. One user request causes 8 internal calls. With example numbers, each call spends 3 ms on JSON and connection setup, but only 0.5 ms with gRPC. How much time does gRPC save for each user request?

<details> <summary>Show answer</summary>

About 20 ms. Each call saves 3 - 0.5 = 2.5 ms. With 8 calls, the saving is 8 x 2.5 = 20 ms for every user request. The saving grows with the number of internal calls, which is why gRPC is popular between services.

</details>

3. A REST API has the endpoint POST /invoices/42/approval-requests. Why does it look strange, and what would the RPC version look like?

<details> <summary>Show answer</summary>

"Approve this invoice" is an action, not a thing. REST works best with resources, so an action must be turned into a strange resource, like "approval requests". In RPC, the action is simply a function, like ApproveInvoice(invoice_id: 42). Many REST APIs accept a few action-style endpoints for cases like this.

</details>

4. A team renames the price field to price_cents in a REST JSON response. An older mobile client still reads price, and it fails in production. How would a gRPC contract help?

<details> <summary>Show answer</summary>

The mistake would appear at build time. With gRPC, both the client code and the server code are generated from the same .proto file. After the rename, code that still uses the old field name does not compile. So the team finds the problem before the release, not after users are affected.

</details>

5. A product page, GET /products/42, is requested 1,000,000 times per day. A CDN answers 90 percent of these requests from its cache. How many requests reach the servers, and what would change if the page data came through gRPC instead?

<details> <summary>Show answer</summary>

100,000 requests reach the servers with REST. The CDN answers 90 percent, so the other 10 percent, or 100,000 requests, reach the servers. Every gRPC call is sent as a POST, so the CDN cannot cache it. All 1,000,000 requests would reach the servers, which is 10 times the load.

</details>