Fundamentals
API styles
REST, gRPC and GraphQL can answer the same request. Pick one by asking who calls the API and what they need from it.
An API style is the set of rules a client follows to ask a server for data. Three styles cover most real systems: REST, gRPC and GraphQL. Each can answer the same question. They differ in what the client has to know and what the server has to guarantee.
Concept
Before you start, know how an HTTP request and response work. Know that Protobuf is a compact binary format for structured data, covered in serialization.
The big idea
Take one question: "get a user with their three most recent orders." Each style asks it differently.
- REST models things as resources, such as
users/u_123, and fetches them with HTTP verbs. - gRPC exposes typed methods, such as
GetUser, with binary messages over HTTP/2. - GraphQL exposes one endpoint and a typed schema. The client asks for exactly the fields it wants.
Pick the style that fits your callers. Don't pick the one you read about most recently.
Walking through it
REST sends a path and query, and the server decides the response shape:
GET /v1/users/u_123?expand=recent_orders&recent_orders_limit=3 HTTP/1.1
Host: api.example.comGraphQL sends a query, and the response contains only the requested fields:
query {
user(id: "u_123") {
name
recentOrders(first: 3) { id totalCents }
}
}The main trade-offs:
| REST | gRPC | GraphQL | |
|---|---|---|---|
| Shape | Resources and HTTP methods | Typed service methods | One endpoint, client picks fields |
| Encoding | Usually JSON | Protobuf (binary) | JSON |
| HTTP caching | Excellent (GET plus CDN) | None built in | Hard, since queries are POSTs to one URL |
| Best for | Public APIs, web, broad compatibility | Internal service-to-service calls | Many clients needing different fields |
GraphQL has a cost that REST doesn't. Resolvers run once per field. Fifty posts, each with an author lookup, can turn one query into 1 + 50 database calls. This is the N+1 problem, and batching the lookups fixes it.
Many companies use all three. REST serves the public API, gRPC connects internal services, and GraphQL sits in front as a backend-for-frontend for their own apps.
Common mistakes
- gRPC for a public API. Outside developers expect JSON they can call with
curl. gRPC needs generated clients. - Assuming GraphQL caches like REST. A single
/graphqlPOST URL gives HTTP caches nothing to key on. - Forgetting the N+1 problem. A GraphQL schema that looks simple can issue dozens of database queries per request.
Check yourself
- Why is REST easier to put behind a CDN than GraphQL? REST GETs have a URL that caches can key on, while GraphQL usually sends everything as a POST to one URL.
- When is gRPC the better choice? For internal service-to-service calls where typed contracts, compact encoding and streaming matter.
Key takeaways
- The three styles answer the same question with different trade-offs.
- REST suits public and web APIs. gRPC suits internal traffic. GraphQL suits many clients with different data needs.
- GraphQL moves complexity to the server, including N+1 queries and caching.
Further learning
The gRPC documentation covers the service and message model in depth.
Next, read about safe methods and idempotency.
Related
API design
An API is a contract that outlives the code behind it. Design the styles, methods, pagination, errors and async flows so changes stay additive.
HTTP/1.1, HTTP/2 and HTTP/3
The protocol of the web. Separates HTTP's meaning (methods, status codes, caching) from its wire format, and shows how each version fixes the latency problem of the one before.
Serialization, schemas and compression
How data becomes bytes for the wire and for disk, how formats like JSON, Protobuf and Avro differ, how to change a schema safely, and when compression pays. Start here for data formats.