Decision guide
REST vs GraphQL vs gRPC
Which API style should you use for a new API?
Side by side
| Criterion | REST | GraphQL | gRPC |
|---|---|---|---|
| Contract | OpenAPI (optional) | Schema (built-in, introspectable) | Protobuf (required) |
| Payload | JSON (text) | JSON (text) | Protobuf (binary) |
| Data shaping | Server-defined; fields/expand | Client-selected | Fixed messages |
| HTTP caching / CDN | Native | Needs persisted GET queries | Not applicable |
| Browser support | Native | Native | Via gRPC-Web / Connect |
| Streaming | SSE / WebSockets | Subscriptions | Native (uni/bi-directional) |
| Error model | Status codes + Problem Details | errors[] + data | Status codes + details |
| Tooling breadth | Ubiquitous | Strong | Strong, developer-focused |
| Typical home | Public/partner APIs | App edge / BFF | Internal microservices |
When to choose each
REST
Resource-oriented JSON over HTTP using standard methods, status codes and caching.
Choose when
- Public or partner APIs
- Simple CRUD-style resources
- You want HTTP caching, CDNs and universal tooling
Avoid when
- Many clients need very different data shapes
- High-throughput internal RPC
GraphQL
Typed schema with client-selected fields through one endpoint.
Choose when
- Many first-party clients (web, iOS, Android) with different needs
- Aggregating several backend services for apps
- Fast-moving product teams
Avoid when
- Public APIs that need simple caching
- File-heavy APIs
- Teams without capacity for cost limits and resolver performance work
gRPC
Protobuf contracts over HTTP/2 with generated clients and streaming.
Choose when
- Internal service-to-service calls
- Low latency / high throughput
- Bi-directional streaming
- Polyglot microservices with strong contracts
Avoid when
- Browser clients without gRPC-Web/Connect
- Public APIs for broad audiences
Verdict
Most organizations use all three: REST for public and partner APIs, GraphQL (or a REST BFF) at the edge for their own apps, and gRPC (plus events) between internal services. Choose per boundary: who are the consumers, how diverse are their needs, and do you need HTTP caching or raw performance?