REST compared with GraphQL, gRPC and tRPC

Pick the protocol that matches the shape of the data and the shape of the clients, and expect to run more than one.

The honest comparison

	REST	GraphQL	gRPC	tRPC
Wire format	JSON over HTTP	JSON over HTTP	Protobuf over HTTP/2	JSON over HTTP
Schema	OpenAPI, optional	SDL, required	`.proto`, required	TypeScript types, inferred
Over-fetching	Common	Solved by the client's selection	N/A, fixed messages	Shaped per call site
Under-fetching	Multiple round trips	One query, many resources	Server streaming	Composed procedures
Caching	HTTP caching works	Much harder, usually persisted queries	No HTTP-level caching	HTTP caching works
Streaming	SSE or WebSocket bolted on	Subscriptions over WebSocket	Native and bidirectional	SSE or WebSocket
Client reach	Anything	Anything	Generated clients, no browsers without a proxy	TypeScript only
Best for	Public APIs, simple resources	Client-driven aggregation	Internal service-to-service	A full-stack TS monorepo

# GraphQL solves the aggregate screen: one request, exactly the fields needed
query OrderScreen($id: ID!) {
  order(id: $id) {
    id
    status
    total { amount currency }
    customer { name }
    items(first: 5) { sku name }
  }
}
# The same screen over REST is typically four calls, or one bespoke endpoint
# that exists only to serve this one page.

// gRPC: a strict contract with streaming, ideal between services you own
service Orders {
  rpc GetOrder (GetOrderRequest) returns (Order);
  rpc WatchOrders (WatchRequest) returns (stream OrderEvent);
}

message GetOrderRequest { string id = 1; }
message Order {
  string id = 1;
  Status status = 2;
  int64 amount_minor = 3;
  string currency = 4;
}

Running them side by side

Keep one source of truth for the domain and translate at the edge. Two implementations of the same business rule diverge within a quarter.
REST for public and partner traffic, because caching and plain HTTP tooling are unbeatable for reach.
GraphQL when client teams are blocked by round trips and the shape of the screen drives the shape of the query.
gRPC between services you own, where the schema is an internal contract and streaming matters.
tRPC only inside a TypeScript monorepo, where the compile-time coupling is a feature rather than a trap.
Do not adopt a second protocol for its own sake. Each adds a gateway, a security surface, an observability story and a set of client libraries to maintain.
Whatever you choose, keep one consistent error model across all surfaces so clients can handle failure once.

💡

The deciding question is rarely expressiveness and usually operations: how will you cache it, how will you trace one request across hops, how will you rate limit it, and who will debug it at 3am. A protocol you can operate beats a protocol that is theoretically nicer.

FAQ

Does GraphQL make REST obsolete?

No. GraphQL moves the shaping work to the client and removes HTTP caching in the process. Public APIs with stable resources usually stay REST for exactly that reason.

Can a browser call gRPC directly?

Not the standard HTTP/2 gRPC protocol. gRPC-Web with a proxy works, but it is an extra component, which is why most teams expose REST or GraphQL at the edge and keep gRPC internal.

Hypermedia and the Richardson maturity model Testing and contract testing REST APIs

Last refreshed 2026-09-18.

REST compared with GraphQL, gRPC and tRPC

The honest comparison

Running them side by side

FAQ

Related