Three API protocols dominate modern system design: REST, GraphQL, and gRPC. Each solves a distinct problem, and none is universally best.
The wrong choice does not usually cause an immediate failure. It creates a slow accumulation of friction: too many round trips to a REST API that does not fit the client's data shape; a GraphQL layer that was added to a simple service that did not need it; gRPC endpoints that the browser team cannot directly consume.
This guide explains how each protocol works, where each genuinely wins, the real costs of each, and a decision framework you can apply to your specific situation.
Quick Comparison
| Dimension | REST | GraphQL | gRPC |
|---|---|---|---|
| Transport | HTTP/1.1 or HTTP/2 | HTTP/1.1 or HTTP/2 | HTTP/2 only |
| Serialisation | JSON (typically) | JSON | Protocol Buffers (binary) |
| Schema / contract | OpenAPI (optional) | Schema (required) | Proto file (required) |
| Client flexibility | Fixed per endpoint | Client-defined queries | Fixed per RPC method |
| HTTP caching | Native (GET responses) | Limited (POST by default) | None |
| Browser support | Full | Full | Requires gRPC-Web proxy |
| Streaming | Limited | Subscriptions | Native (server, client, bidirectional) |
| Learning curve | Low | Medium | Medium-High |
| Best for | Public APIs, CRUD, broad compatibility | Diverse clients, flexible data needs | Internal services, high throughput, streaming |
REST: The Default That Is Often Right
REST (Representational State Transfer) is not a protocol — it is an architectural style that uses HTTP verbs and URL-addressed resources. Its ubiquity means every HTTP client, every caching layer, every monitoring tool, and every developer already understands how it works.
Where REST wins
Caching. GET responses are cacheable by CDNs, reverse proxies, and browser caches natively. For read-heavy public APIs, this reduces backend load dramatically and can serve the majority of traffic from cache without code changes.
Simplicity and tooling. Every language has HTTP client libraries. OpenAPI (Swagger) provides schema definition, code generation, and documentation. API testing with curl or Postman requires no special client setup.
Third-party developer experience. Public APIs consumed by developers you do not control should almost always be REST. The approachability and tooling availability are unmatched.
Incremental adoption. REST APIs can be built incrementally without defining a full schema upfront. This matters for early-stage products where the data model is still evolving.
Where REST struggles
Over-fetching. A REST endpoint returns a fixed shape. If the mobile app only needs 3 of the 20 fields the endpoint returns, the other 17 travel over the wire anyway.
Under-fetching. A single screen that needs data from three resources requires three round trips, or a bespoke aggregation endpoint that couples the API to a specific client's needs.
Versioning. Breaking changes to a REST endpoint require versioning (/v2/), which creates API surface to maintain indefinitely. GraphQL and gRPC handle schema evolution more gracefully through deprecation.
GraphQL: The Right Tool for Flexible Data
GraphQL is a query language where the client specifies exactly what data it needs. Instead of multiple endpoints each returning a fixed shape, there is typically one endpoint that accepts a query describing the required data.
query {
user(id: "123") {
name
email
orders(last: 5) {
id
total
status
}
}
}
The server returns exactly what was requested — no more, no less.
Where GraphQL wins
Diverse clients with different data needs. A web dashboard needing detailed data and a mobile app needing a subset can both query the same GraphQL API and get exactly what each needs, without the API team building separate endpoints for each client.
Reducing round trips. A single GraphQL query can fetch nested, related data that would require multiple REST calls. For mobile apps on variable connections, this matters.
Self-documenting schema. The GraphQL schema is the contract between client and server. Introspection lets clients discover available types and operations, and tools like GraphiQL and Apollo Studio provide interactive documentation automatically.
Rapid frontend iteration. Frontend teams can add fields to their queries without waiting for API changes, as long as the schema already exposes the data.
Where GraphQL struggles
HTTP caching. Because most GraphQL queries go to a POST endpoint, standard HTTP caching does not apply. Solutions exist (persisted queries, GET-based queries for reads) but require additional implementation effort.
N+1 query problem. Naive GraphQL resolver implementations fetch data per-record rather than batching — a query for 100 orders that also fetches each order's user can trigger 101 database queries. DataLoader or equivalent batching is required to avoid this.
Introspection as an attack surface. By default, GraphQL exposes its full schema through introspection — a useful developer tool that also reveals your data model to anyone who can reach the endpoint. Disable introspection in production for non-public APIs.
Complexity for simple APIs. A CRUD API for an admin panel does not need GraphQL. The schema overhead and N+1 vigilance are costs that only pay off when the flexibility is actually needed.
gRPC: High-Performance Internal Services
gRPC is a Remote Procedure Call framework from Google. It uses Protocol Buffers (protobuf) for serialisation and HTTP/2 for transport.
A service is defined in a .proto file:
service OrderService {
rpc GetOrder (GetOrderRequest) returns (Order);
rpc ListOrders (ListOrdersRequest) returns (stream Order);
rpc CreateOrder (CreateOrderRequest) returns (Order);
}
Code generation from the .proto file produces type-safe client and server stubs in your target language — Go, Java, Python, Node.js, C#, and others.
Where gRPC wins
Performance. Protocol Buffers are significantly smaller and faster to serialise/deserialise than JSON. HTTP/2 multiplexing eliminates head-of-line blocking. For high-throughput internal services, gRPC delivers measurably lower latency and higher throughput.
Streaming. gRPC supports server streaming (one request, many responses), client streaming (many requests, one response), and bidirectional streaming — use cases where REST requires WebSockets or SSE and GraphQL requires subscriptions.
Strong contracts. The .proto file is the source of truth. Generated code means breaking changes in the service definition fail compilation in clients before reaching runtime.
Polyglot microservices. In a microservices architecture with services written in different languages, generated clients from a shared proto definition keep the contract consistent without language-specific negotiation.
Where gRPC struggles
Browser compatibility. gRPC uses HTTP/2 features that browsers cannot access directly. A gRPC-Web proxy layer (Envoy, nginx) is required to serve browser clients, adding infrastructure overhead.
Debugging difficulty. Binary Protocol Buffers are not human-readable. Tools like grpcurl and Postman's gRPC support help, but debugging gRPC traffic is still harder than reading JSON in a curl response.
Learning curve. Teams new to protobuf and code generation take time to reach productivity. The deployment and tooling requirements are higher than REST.
Decision Framework
By primary use case
| Use case | Recommended protocol |
|---|---|
| Public API for third-party developers | REST |
| Web or mobile app with diverse data needs | GraphQL |
| Internal service-to-service in microservices | gRPC |
| Simple CRUD backend | REST |
| High-throughput data pipeline between services | gRPC |
| API Gateway aggregating multiple backends | GraphQL |
| Real-time streaming between services | gRPC |
| API with heavy read caching via CDN | REST |
By team and context
| Context | Recommendation |
|---|---|
| Small team, early-stage product | REST — minimize operational complexity |
| Multiple frontend teams with different data needs | GraphQL — single flexible API surface |
| Platform team building internal service mesh | gRPC — performance and contract strength |
| Public-facing developer API | REST — broadest tooling and approachability |
| Polyglot microservices with strict contracts | gRPC — generated clients from shared proto |
Combining Protocols
Many production systems use more than one protocol:
GraphQL gateway over gRPC services is a common pattern at scale. Frontend clients talk GraphQL (flexible queries, one endpoint), while the GraphQL server aggregates data from internal gRPC services (fast, strongly-typed). Each layer gets its optimal protocol.
REST public + gRPC internal separates the developer-facing API (REST, stable, cacheable) from the internal service mesh (gRPC, fast, strongly-typed). The boundary is the API gateway.
Introduce a second protocol only when there is a specific, measurable problem it solves — not to follow a pattern. Each additional protocol is operational surface your team must understand and maintain.
For help designing an API architecture that fits your system — whether that is a REST public API, a GraphQL layer for a complex frontend, or a gRPC service mesh for microservices — see our Enterprise Software Development capabilities or get in touch.
If you are designing an API, security needs to be part of the design from the start. Our API Security Best Practices guide covers the controls that apply regardless of which protocol you choose.