Explain the difference between REST APIs and GraphQL.
REST: multiple endpoints, fixed response shapes, prone to over/under-fetching, easy HTTP caching. GraphQL: one endpoint, client specifies exactly the fields it needs, great for complex/nested data, but caching and rate-limiting are harder. Neither is universally better.
REST and GraphQL are two API styles with opposite trade-offs — the answer is knowing when each fits.
REST
Resources exposed as multiple endpoints, each returning a fixed shape:
GET /users/1
GET /users/1/posts
GET /posts/5/comments- Over-fetching — the endpoint returns fields you don't need.
- Under-fetching — you need 3 endpoints to build one screen → request waterfalls (the "N+1 endpoints" problem).
- HTTP caching is easy — each URL is cacheable by browsers, CDNs, proxies.
- Simple, ubiquitous, great tooling, stateless.
GraphQL
A single endpoint; the client sends a query describing exactly the data it wants:
query {
user(id: 1) {
name
posts { title comments { text } }
}
}- No over/under-fetching — you get precisely the fields and depth requested, in one round-trip.
- Strongly typed schema — self-documenting, great DX, introspection.
- Caching is harder — one POST endpoint, so HTTP/CDN caching doesn't apply; you rely on a client cache (Apollo, urql, Relay) keyed by entity IDs.
- Other hard parts — rate limiting and query-cost analysis (a malicious deep query can be expensive), N+1 on the server (needs DataLoader), more upfront setup.
When to use which
- REST — simple/CRUD-shaped resources, public APIs, when HTTP caching matters, file uploads, small teams.
- GraphQL — complex, deeply nested, highly relational data; many client types (web/mobile) each needing different shapes; rapidly evolving frontends that shouldn't wait on new backend endpoints.
It's not either/or — many systems use REST for some things and GraphQL for others, and tools like tRPC offer a third path.
The framing
"REST is multiple fixed-shape endpoints — simple and HTTP-cacheable, but you over-fetch fields and under-fetch resources, causing waterfalls. GraphQL is one endpoint where the client asks for exactly the fields it needs in one round-trip — excellent for complex nested data and multiple clients — but you trade away easy HTTP caching and take on rate-limiting and server-side N+1 concerns. Choose by data shape and caching needs; they're not mutually exclusive."
Follow-up questions
- •Why is caching harder with GraphQL?
- •What is over-fetching vs under-fetching?
- •How does GraphQL handle the N+1 problem on the server?
- •When would you still choose REST over GraphQL today?
Common mistakes
- •Claiming GraphQL is strictly better than REST.
- •Ignoring that GraphQL loses easy HTTP/CDN caching.
- •Forgetting GraphQL needs query-cost limiting to prevent abuse.
- •Not mentioning over-fetching/under-fetching — the core REST pain point.
Performance considerations
- •GraphQL reduces round-trips and payload size by fetching exactly what's needed, but pushes caching into the client and risks expensive queries. REST gets cheap edge/CDN caching but can cause request waterfalls.
Edge cases
- •File uploads — awkward in GraphQL, natural in REST.
- •A deeply nested GraphQL query that's extremely expensive to resolve.
- •Versioning — REST uses versioned URLs, GraphQL evolves the schema with deprecations.
Real-world examples
- •GitHub offers both a REST and a GraphQL API for the same data.
- •Mobile apps using GraphQL to fetch tailored, minimal payloads over slow networks.