REST vs GraphQL: Which API Style Should You Use?
REST and GraphQL are two different answers to the same question: how should an API expose data to a client? The real decision isn't "which is more modern" — it's whether you're willing to give up free HTTP caching for a query language that fetches exactly what the client asks for.
The quick answer
| REST | GraphQL | |
|---|---|---|
| Shape | Fixed per endpoint (GET /users/42 always returns the same shape) | Client-specified per request |
| Endpoints | Many, one per resource | Usually one |
| Over/underfetching | Common — you get exactly what the endpoint defines, no more or less | Fixed by design — you ask for exactly the fields you need |
| HTTP caching | Free — a GET is cacheable by URL out of the box | Not out of the box — needs its own caching layer |
| Best for | Public APIs, CRUD resources, simple clients | Multiple clients needing very different shapes of the same data |
Reach for REST when
- It's a public API, a CRUD-shaped resource, or anything that benefits from standard HTTP caching, versioning, and tooling that already assumes REST (most API gateways and monitoring do).
- You have one kind of client and its data needs are fairly uniform.
Reach for GraphQL when
- You have genuinely different clients wanting different slices of the same data — a web app, an iOS app, and a smartwatch app each needing their own shape is the textbook case.
- The team can afford building the server-side resolver and batching layer GraphQL requires.
The tradeoff most comparisons skip: caching
This is the one that actually matters for a system design decision. REST's one-URL-per-resource model means a browser, CDN, or reverse proxy can cache a GET /users/42 request with zero extra work — caching is a property of the protocol itself. GraphQL typically exposes a single endpoint reached via POST, which means none of that standard caching infrastructure applies automatically. A GraphQL server has to build its own caching (normalized client-side caches like Apollo, or persisted queries) — real engineering work that REST gets for free.
The other GraphQL-specific cost worth knowing: the N+1 problem. Naively resolving a nested query (a list of users, each resolving its own orders) fires one database query per item instead of one batched query for everyone — unless the server explicitly batches those resolutions.
The real-world answer: often both
Many production systems use REST at the edge for simple, cacheable resources, and GraphQL for one specific client-facing aggregation layer that genuinely needs to serve different shapes to different clients — not one or the other for the whole system.
Go deeper
The full lesson has a diagram comparing the request shapes directly, walks through the N+1 problem with a concrete example, and gives the interview framing for defending whichever choice you make:
👉 Read the full REST vs GraphQL lesson — part of the free System Design Lab course.