Picking an API protocol shapes your client experience, your throughput, your tooling, and your caching story for years. "We'll use REST" is the lazy default, often the wrong one. gRPC is 7× faster but kills browser usability. GraphQL solves over-fetching but introduces N+1 query problems. Each protocol was designed to solve a specific pain — know which pain you have.
| Protocol | Encoding | Schema | Ideal use |
|---|---|---|---|
| REST | JSON over HTTP/1.1 or /2 | Optional (OpenAPI / Swagger) | Public APIs, CRUD, browser clients |
| GraphQL | JSON over HTTP (usually POST /graphql) | Required (typed schema) | Client-flexible queries, mobile data-saving, aggregation layer |
| gRPC | Protobuf over HTTP/2 | Required (.proto file) | Internal service-to-service, high-throughput, streaming |
Resources addressed by URL, verbs (GET/POST/PUT/DELETE) as operations. Stateless, cacheable, human-readable.
Strengths: every developer knows it. HTTP caching works out of the box. Browsers handle it natively. Tools (curl, Postman, jq) just work.
Weaknesses:
One endpoint. Client sends a query specifying exactly which fields of which types it wants. Server returns exactly that — no more, no less.
{
user(id: 42) {
name
posts(limit: 5) {
title
comments { author, text }
}
}
}
One round-trip replaces 3-5. Mobile clients ship far fewer bytes. Backend can evolve fields freely — adding a field doesn't break old clients because they don't ask for it.
Catches:
DataLoader-style batching.Best for: client-flexible data (mobile apps), aggregator layers over multiple microservices, internal dashboards. Shopify, GitHub, Facebook expose GraphQL APIs.
gRPC uses Protocol Buffers (binary, schema-defined) over HTTP/2. Compared to REST+JSON:
stream Request → stream Response. Essential for server-push APIs..proto for every major language. Typed client in seconds.But: it doesn't work in browsers natively (needs gRPC-Web proxy). Intermediaries (LBs, debuggers, humans) can't read requests without protoc. HTTP caching doesn't apply. So gRPC's sweet spot is internal, high-RPS service-to-service. External APIs usually stay REST or GraphQL.
REST for public APIs. GraphQL as the aggregation layer for mobile + SPA clients. gRPC between internal services. Each tool plays to its strength; hybrid stacks are normal at scale.
| Metric | REST + JSON | GraphQL + JSON | gRPC + Protobuf |
|---|---|---|---|
| Payload size (1 user obj) | ~450 B | ~280 B (only requested fields) | ~80 B |
| Serialize CPU | ~3 μs | ~3 μs | ~0.5 μs |
| P50 latency (intra-DC) | ~1.2 ms | ~1.5 ms | ~0.3 ms |
| Throughput per core | ~25k RPS | ~18k RPS | ~80k RPS |
| Browser support | Native | Native (via fetch) | gRPC-Web proxy required |
| Streaming | SSE bolt-on | Subscriptions (WS) | Native bidirectional |
| Tooling maturity | Excellent (curl, Postman) | Good (GraphiQL) | Hard to inspect (binary) |
Every Stripe API is REST. Strict versioning, webhooks. The gold standard for public REST APIs.
Both supported. GraphQL endpoint lets third-party clients fetch exactly the fields they need.
Their public API is GraphQL-first — allows themes and headless storefronts to query what they need.
Inside both, almost every service call is gRPC. Public-facing APIs are usually REST with an internal gRPC implementation.
News feed backend uses gRPC between microservices; exposes REST/GraphQL to mobile clients. E-commerce uses REST publicly + gRPC internally. Uber uses gRPC for driver app ↔ dispatch (low-latency streaming).
