Lesson 19 of 30

GraphQL vs REST

Q: When would you choose GraphQL over REST for a new API? What are the real costs of that choice?

A strong answer covers: GraphQL solves over-fetching (unused fields) and under-fetching (needing multiple requests for related data) by letting the client specify the exact shape needed; Real costs: HTTP caching doesn't map cleanly to a single-URL/POST-body API; the N+1 query problem still needs server-side solving (e.g. batching); REST's simplicity is a genuine advantage for small, stable, predictable APIs — this is a tradeoff, not a strict upgrade.

REST fixes what shape of data a URL returns; GraphQL lets the client ask for exactly the fields it needs — trading server-side simplicity for client-side precision, not a strict upgrade.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A screen needs a user's name and their last 3 orders. With a REST API where /users/:id and /users/:id/orders are separate endpoints, how many requests does this typically need? How does GraphQL change that?

REST typically needs two requests; GraphQL can get both in one queryBoth REST and GraphQL always need exactly one request for thisGraphQL always needs more requests than REST because of its query language overhead

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on GraphQL vs REST

What interviewers actually ask about this, and what a strong answer has to cover.

When would you choose GraphQL over REST for a new API? What are the real costs of that choice?

A strong answer covers

GraphQL solves over-fetching (unused fields) and under-fetching (needing multiple requests for related data) by letting the client specify the exact shape needed
Real costs: HTTP caching doesn't map cleanly to a single-URL/POST-body API; the N+1 query problem still needs server-side solving (e.g. batching)
REST's simplicity is a genuine advantage for small, stable, predictable APIs — this is a tradeoff, not a strict upgrade

Likely follow-ups

What is the N+1 query problem, and how is it typically solved in a GraphQL server?
How do GraphQL clients like Apollo handle caching, given that HTTP caching doesn't apply cleanly?
Would you introduce GraphQL for a simple CRUD app with five resources? Why or why not?

Practice these with the AI interviewer →

The plain-language idea

A REST endpoint returns a fixed shape: GET /users/42 gives you whatever fields that endpoint was built to return, whether your screen needs all of them or not. Need a user's name and their last 3 orders? That's often two separate requests (/users/42, /users/42/orders) — or a new custom endpoint someone has to build.

GraphQL exposes one endpoint and lets the client describe exactly what it needs, in one request:

query {
  user(id: 42) {
    name
    orders(limit: 3) {
      total
      date
    }
  }
}

The server returns exactly (and only) the shape asked for — no unused fields sent over the wire, and no second request needed for related data that a REST endpoint didn't happen to include.

GraphQL vs REST: asking for a shape, not an endpointStep 1 of 3

REST: GET /users/42 returns the WHOLE user object, whether you need all of it or not — over-fetching.

What people usually miss

Watch out

GraphQL isn't automatically faster. A single GraphQL query can still trigger many separate database lookups underneath (the "N+1 query problem") — solving that server-side (often with a batching layer like DataLoader) is real, necessary work, not something GraphQL solves for free.
HTTP caching (the ETag/Cache-Control lesson) doesn't apply cleanly to GraphQL. Nearly every GraphQL request is a POST to the same single URL with a different body, which breaks the URL-based caching REST naturally gets — GraphQL clients (Apollo, Relay) implement their own object-level caching instead.
REST's simplicity is a real advantage for simple APIs. A small, stable set of resources with predictable access patterns often doesn't need GraphQL's added complexity (schema, resolvers, a query language) — this is a genuine tradeoff, not GraphQL strictly winning.

Why this matters in interviews

"When would you choose GraphQL over REST?" is a real architecture question with a real tradeoff-based answer — a strong response names over/under-fetching as the specific problem GraphQL solves, and the real costs (caching complexity, N+1 queries) it introduces in exchange.