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

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 createUser or sendEmail, 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

Match the style to what the client actually needs

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.

Style	Advantages	Disadvantages	Fits
REST	Standard, cacheable, easy to debug	Over/under-fetching	Public APIs, CRUD resources
GraphQL	Fetches exactly what’s needed, flexible	Hard to cache, more complex	Many clients needing different data shapes
gRPC	Fast, type-safe, streaming	Not human-readable, more tooling	Internal microservices, high performance
JSON-RPC	Simple	Tight coupling, no standard URL conventions	Internal tools, simple integrations

Common mistakes

Choosing GraphQL because it’s trendy Symptom:

The API has one client that needs one fixed shape of data
GraphQL gets adopted anyway, adding complexity with no real benefit
REST is the better fit when the use case is that straightforward

Using REST for internal microservices that need performance Symptom:

Services call each other 100 times per request — HTTP overhead adds up
gRPC or a message queue fits high-frequency internal calls better

💡 Real-world examples

GitHub:

Runs both a REST API (v3) and a GraphQL API (v4)

REST for simple operations, GraphQL for complex queries spanning several resources

Netflix:

Uses gRPC for internal service-to-service calls

Uses GraphQL/REST at the edge, where client and partner traffic terminates

Sources: Netflix TechBlog — Practical API Design at Netflix, Netflix CNCF case study