Choosing an API Style — REST vs GraphQL vs gRPC
Three answers to "how do services talk?"
Once you have more than one service, you must choose how they communicate. The three dominant styles optimise for different things, and an interviewer wants to hear why you'd pick one — not a recitation of features. Your REST vs RPC trade-off covers the protocol axis; this page is the practical decision among the three you'll actually reach for.
REST — resources over HTTP
REST models the world as resources (/users/42) manipulated with HTTP
verbs (GET/POST/PUT/DELETE). It is stateless, cache-friendly (HTTP caching "just works"), and
universally understood. Its weaknesses are over-fetching (the endpoint returns more
than you need) and under-fetching (you call three endpoints to assemble one screen).
GraphQL — the client specifies the shape
GraphQL exposes a single endpoint and a typed schema; the client sends a query describing exactly the fields it wants, and gets precisely that — no more, no less. This kills over/under-fetching and is ideal for rich frontends and aggregating many backends (BFF pattern). The costs: HTTP caching no longer works out of the box (everything is a POST to one URL), and a careless query can be expensive, so you need depth/complexity limits.
gRPC — fast, typed, service-to-service
gRPC uses Protocol Buffers (a compact binary format) over HTTP/2, with a strict contract and code generation in many languages. It is the fastest of the three and supports streaming, which makes it the go-to for internal microservice-to-microservice calls. The trade-off: binary payloads aren't human-readable, and browsers can't speak raw gRPC without a proxy (gRPC-Web), so it's rarely a public-facing browser API.
The decision table
| REST | GraphQL | gRPC | |
|---|---|---|---|
| Transport / format | HTTP + JSON | HTTP + JSON (single endpoint) | HTTP/2 + Protobuf (binary) |
| Contract | Loose (OpenAPI optional) | Strong (typed schema) | Strong (.proto, codegen) |
| Fetching | Over/under-fetch | Exact fields the client asks for | Fixed messages, very efficient |
| Caching | Excellent (native HTTP) | Hard (needs app-level) | Manual |
| Streaming | Limited (SSE/WebSocket) | Subscriptions | First-class (bi-directional) |
| Best for | Public APIs, CRUD, broad reach | Rich/aggregating frontends | Internal service-to-service |
How to answer in an interview
- Public API for third parties or simple CRUD? → REST. Ubiquity and caching win.
- Complex frontend pulling from many sources? → GraphQL. Eliminate round-trips and over-fetching.
- Chatty internal microservices needing low latency / streaming? → gRPC.
- Real systems mix them: REST/GraphQL at the edge through an API gateway, gRPC between services behind it.
Re-authored for this guide, with concepts and diagrams adapted from Karan Pratap Singh’s System Design (course, MIT licence) and the System Design Primer (CC BY 4.0). Diagrams © their respective authors.
🤖 Don't fully get this? Learn it with Claude
Stuck on Choosing an API Style — REST vs GraphQL vs gRPC? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **Choosing an API Style — REST vs GraphQL vs gRPC** (System Design) and want to truly understand it. Explain Choosing an API Style — REST vs GraphQL vs gRPC from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Socratic — adapts to where you're stuck.
Teach me **Choosing an API Style — REST vs GraphQL vs gRPC** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Active recall exposes what you missed.
Quiz me on **Choosing an API Style — REST vs GraphQL vs gRPC** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Intuition + hook + flashcards for long-term memory.
Help me remember **Choosing an API Style — REST vs GraphQL vs gRPC** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.