Prerequisites
Read these first if REST as an architectural style, RPC, or HTTP methods/URLs are new.
- Fielding — REST (ch. 5) — resources and uniform interface, not “JSON over GET”
- gRPC core concepts — RPC as named procedures, often on HTTP/2
- Remote procedure call — the older “call a function on another process” model REST is an alternative to
- HTTP overview (MDN) — methods, URLs, status codes; the shared pipe both ride
“Is this a REST API or an RPC?”
Design reviews often treat REST and RPC as rival products. They are rival vocabularies for the same problem: how one process asks another for work over the network. Both can ride HTTP and return JSON. Both can power a mobile app. The fork is what you name and version — resources you manipulate, or procedures you call — not which logo wins.
This post is that contract-level distinction. Cellular round-trips live in Fat vs Chatty APIs; those concerns stack and do not replace each other.
One inbox, two contracts
For example, in a mail app the same “open this message” need can be carved either way:
| Resource-oriented (REST-ish) | Procedure-oriented (RPC-ish) | |
|---|---|---|
| Unit of design | Noun / resource | Verb / method |
| Example | GET /messages/42 |
GetMessage(id=42) or POST /rpc/GetMessage |
| Uniform interface | Shared HTTP verbs + status | Per-service method catalog |
REST (Representational State Transfer) is a style. In the HTTP mapping most teams mean, URLs name resources and verbs say what to do. Day-to-day “REST APIs” are usually resource-oriented HTTP. RPC names operations — classic stacks made that literal; gRPC, JSON-RPC, and many POST /api/v1/sendMessage endpoints keep the procedure as the unit even on HTTP.
They are alternatives for modeling the contract. A shop can expose REST at the edge and gRPC between services, or run RPC-shaped JSON on the same gateway that hosts CRUD resources.
What the phone actually notices
From an Android client, the wiki label matters less than three facts — that is the proof of the vocabulary claim.
Client shape. Retrofit against resource URLs fits CRUD screens. A generated RPC stub fits when the backend already speaks Protobuf methods. Either way you still own timeouts, cancellation, and partial failure for the screen.
Chatty vs fat is orthogonal. Six GETs per list row is a REST usage smell; six tiny RPCs is the same smell with different names. Aggregating for cellular can sit behind a BFF whether the public face is resource JSON or a GetInboxPage RPC.
Evolution and tooling. Resource APIs lean on HTTP caching, CDNs, and browser-friendly debugging. RPC/gRPC leans on shared schemas, codegen, and (for gRPC) binary framing that needs a gateway for browsers. Public partner edges still skew REST-ish; internal meshes often skew RPC for typing and throughput — hybrid, not winner-take-all.
Skip the false fights. Binary Protobuf does not forgive a chatty screen contract on one bar of cellular. POST does not mean “not REST”; POST /getUser can still be RPC in a trench coat — judge by whether resources and uniform verbs are the organizing idea. GraphQL is a third vocabulary (the client shapes a query); it often replaces a cluster of chatty GETs the way a fat BFF method would, without settling the REST-vs-RPC argument.
Prefer resource-oriented HTTP when many clients need a stable, cache-friendly vocabulary over entities. Prefer RPC (often gRPC internally) when both ends are under your control and you want a typed method catalog or streaming. Prefer both when the edge must stay boring and the mesh must stay fast. Put aggregation where product screens need it; do not pretend the wire style alone fixed cellular physics.
For a mail-style inbox open, that usually means a fat edge method or resource page for the phone, and whatever mesh style the backends already speak behind it. The design review question is “what is the unit of the contract?” — noun or verb — not “are we a REST company?”
References
- gRPC vs REST (Postman) — accessible side-by-side of styles and tooling
- Service-to-service: REST, gRPC, and events (freeCodeCamp) — hybrid production pattern
- gRPC vs REST (Toptal) — performance and when complexity pays off