Skip to main content

REST vs GraphQL

REST and GraphQL are two different answers to the same question: how should an API expose data to a client? REST models an API as a set of resources, each with its own URL; GraphQL models an API as a single queryable graph, where the client describes exactly what shape of data it wants in one request. Neither is a networking protocol on its own — both typically ride on top of HTTP/HTTPS — the difference is entirely in how the request/response contract is structured.

REST: many endpoints, fixed shapes​

A REST (Representational State Transfer) API exposes one URL per resource, and lets the HTTP method say what you're doing to it — GET /users/42, POST /orders, DELETE /orders/17. Each endpoint returns a fixed, predetermined shape of data. This maps naturally onto the method/status-code vocabulary covered in APIs, and because a resource is addressed by a stable URL, REST responses plug directly into standard HTTP caching (a CDN or browser can cache GET /users/42 by URL with zero GraphQL-specific tooling) — see CDN.

The cost of "fixed shape" is that clients often don't want exactly that shape:

  • Overfetching — a mobile client that only needs a user's name gets the entire user object anyway, because the endpoint always returns everything.
  • Underfetching — a screen that needs a user and their recent orders has to make two round trips (or a special-purpose combined endpoint has to be built and maintained just for that one screen).

GraphQL: one endpoint, client-specified shape​

GraphQL flips this around: there's typically a single endpoint, and the client sends a query describing exactly the fields it wants, across however many related objects, in one request.

System Design Lab

This directly fixes over/underfetching — the client gets precisely what it asked for in exactly one round trip, which matters a lot on slow or metered mobile connections where every extra request has real latency cost. It comes at the cost of moving complexity server-side: a GraphQL server has to resolve an arbitrary, client-specified query graph, which introduces its own well-known trap — the N+1 problem, where naively resolving nested fields (a list of users, each resolving its own orders separately) fires one database query per item instead of one batched query for all of them, unless the server explicitly batches those resolutions.

Caching is the sharpest practical difference​

This is worth calling out explicitly in an interview, because it's the tradeoff that most concretely affects system design: REST's one-URL-per-resource model means HTTP caching (browser, CDN, reverse proxy) works for free — a GET request is cacheable by URL with no extra effort. GraphQL's single endpoint, typically reached via POST with a query body, means none of that standard caching infrastructure applies out of the box; GraphQL servers instead build their own field-level or response-level caching (e.g. via a normalized client-side cache like Apollo, or persisted queries on the server), which is real engineering work that REST gets for free from the protocol.

When to reach for which​

  • REST is the safer default for public APIs, CRUD-shaped resources, and anything that benefits from HTTP-native caching, straightforward versioning, and tooling that already assumes REST (most API gateways, most monitoring).
  • GraphQL earns its complexity when clients have genuinely varied, nested data needs — a product with a web app, an iOS app, and a smartwatch app each wanting a different slice of the same underlying data is the textbook case — and when the team can afford the server-side cost of a proper resolver and batching layer.

Many real systems use both: REST at the edge for simple, cacheable resources, GraphQL for one specific client-facing aggregation layer that has to serve genuinely different shapes to genuinely different clients.

Why this matters in an interview​

"We'll use GraphQL" without justification is a weaker answer than naming the actual driver — heterogeneous clients needing different shapes of the same data, and a willingness to own the caching and N+1 tradeoffs that come with it. If the design is a fairly standard CRUD API with one kind of client, that's a signal REST is the simpler, better-supported choice, not a default to reach past.

Choosing GraphQL over REST: pros and cons​

Pros

  • Client specifies exactly the fields it needs, fixing over- and underfetching
  • One round trip for data that would otherwise need several REST calls
  • A single, strongly typed schema documents the entire API surface

Cons

  • Standard HTTP caching (CDN, browser) doesn't apply out of the box
  • Naively resolved nested queries can trigger the N+1 problem server-side
  • Harder to rate-limit or monitor per "endpoint" — everything is one URL

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.