GraphQL and REST API Models Compared

The Home Screen That Wanted Four Requests

A storefront app opens its home screen. The layout needs four things: a featured carousel (image, title, price), a cart badge with an item count, the signed-in user's first name, and three recommendations.

The frontend wires a waterfall of REST calls:

Two separate wastes appear here.

Over-fetching is response data the client never reads. The product payloads are mostly bytes that are parsed, held in memory, and dropped. On a mid-range phone that means extra JSON parsing, larger GC pressure, and more radio time for data nobody renders.

Under-fetching is the opposite failure: no endpoint matches the screen, so the client issues four requests and waits out four round trips. Latency multiplies with the number of calls, and the four responses can even arrive out of order.

GraphQL attacks both at once. One endpoint, one request, and the selection set is the UI contract:

query HomeScreen {
  featuredProducts(limit: 6) {
    id
    title
    priceCents
    imageUrl
  }
  cart {
    itemCount
  }
  me {
    firstName
  }
  recommendations(limit: 3) {
    id
    title
    priceCents
    imageUrl
  }
}

The response mirrors the query shape, so the client does no pruning and the server does not ship the 30 unused product fields.

One honest limit: GraphQL removes bytes and round trips, not computation. The server still walks every field you asked for, so a greedy query can cost more than four REST calls did. That cost is controlled later with depth limits and budgets, covered in query depth limits.

The Cache You Give Up and the One You Rebuild

GET /products/featured is cacheable for free. The URL names the resource, Cache-Control and ETag set the policy, and the browser, the CDN, and every proxy in between can store the exact bytes without understanding anything about your API. This is REST's quiet advantage, and it is the single most common reason teams talk themselves out of GraphQL.

A GraphQL request is almost always POST /graphql, and HTTP caches do not cache POST bodies. The cache key is built from method and URL; the operation lives in the request body, so two different queries to the same endpoint are indistinguishable to an intermediary. GraphQL therefore needs deliberate caching design at one of three layers:

1. GET with a query string. GET /graphql?query=query%7B...%7D is cacheable like any URL, but URL length limits (proxies often cap around 2 KB) restrict it to short queries and it produces URLs no human wants to read.
2. Persisted queries. The client sends a hash instead of the document; the CDN keys on the hash and serves cached responses without ever seeing the text. See persisted queries.
3. Entity-level response caching. The server caches per entity (Product:123) and assembles the response from cached pieces, so the cache survives changes in which fields a client requests. See response caching strategy.

Client libraries add a fourth layer of their own: a normalized cache keyed on __typename plus id, so the same product fetched by two different queries is stored and rendered once. That is why an id field on every object type is treated as a convention rather than a preference.

The trade is real: you buy exact payloads and fewer requests, and you pay for caching infrastructure you would otherwise get from a plain HTTP cache.

Versionless Does Not Mean Effortless

REST teams version by URL. When GET /v1/products changes shape incompatibly, you ship /v2/products, run both paths, duplicate CDN entries, and wait months for old clients to migrate. Every version doubles the surface you test.

GraphQL takes a different route: the endpoint never changes, so the schema must evolve without breaking anyone. The safe moves are additive. Adding a nullable field changes nothing for existing queries. Changing a field's type, removing a field, or tightening nullability breaks queries that already exist in the wild, so those changes go through a cycle instead:

1. Mark the old field @deprecated(reason: "use priceCents"), which keeps it resolvable while surfacing a warning in tooling.
2. Ship the replacement field and let clients migrate query by query.
3. Remove the old field only after telemetry shows zero traffic.

That cycle is only trustworthy if something enforces it. Schema checks in CI compare the proposed schema against the current one and block merges that break existing operations, see schema checks in CI and schema evolution rules. Without that gate, "we just add fields" quietly turns into "someone removed one last Tuesday."

When REST is still the right answer

• The API is a clean resource CRUD surface and responses should be cacheable at the CDN by URL.
• The work is file upload, download, or webhook delivery, where a request body of raw bytes beats a JSON envelope.
• There is one client, one team, and the schema would be ceremony rather than leverage.
• Server-to-server traffic where the consumer already shares your code and needs no discoverability.

Interviewers probe exactly here. "When would you not use GraphQL?" earns a real answer when you name a concrete cost: caching-by-URL you would have to rebuild, resolver composition you would have to staff, or a governance process you would have to run. A framework that fits everywhere fits nowhere in particular.