REST vs RPC vs GraphQL
REST is one way to build an API, not the only way. Knowing the alternatives sharpens your sense of when REST is the right tool.
Three styles
Section titled “Three styles”- REST organizes the API around resources (nouns) you act on with standard HTTP methods. Strengths: caching for free, a uniform interface, great fit for CRUD-style domains and public APIs. Weakness: clients sometimes over-fetch (get more fields than they need) or under-fetch (need several round trips).
- RPC organizes the API around procedures (verbs) — you call named operations like
createUserorsendEmail, often over HTTP POST or gRPC. Strengths: a natural fit for action-oriented APIs and internal service-to-service calls. Weakness: less uniform, weaker HTTP caching, the surface grows with every new verb. - GraphQL exposes a single endpoint and a query language: the client asks for exactly the fields it wants. Strengths: no over/under-fetching, one round trip for complex screens. Weakness: HTTP caching is harder, and the server must guard against expensive queries.
flowchart TD
Need{What does the client need?} --> CRUD[Resource CRUD, public API, caching]
Need --> Action[Action-oriented, internal services]
Need --> Flexible[Flexible field selection, many clients]
CRUD --> REST
Action --> RPC
Flexible --> GraphQL Choosing
Section titled “Choosing”Reach for REST when your domain is naturally resource-shaped, you want HTTP caching and a broadly understood public contract, and CRUD-plus-a-few-actions covers the use cases — which is most web and mobile back ends. Reach for RPC/gRPC for high-throughput internal service calls. Reach for GraphQL when many different clients need different slices of a rich, interconnected data graph.