Back to Networking
Networking
medium
mid

What is 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.

4 min read·~6 min to think through

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:

ts
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:

graphql
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.

Senior engineer discussion

Seniors present it as a trade-off, not a winner: GraphQL's flexibility vs. REST's caching simplicity, and the operational costs GraphQL adds (client cache, query-cost limiting, DataLoader). They choose based on data shape, client diversity, and caching strategy.

Related questions