REST or GraphQL?
“When would you choose GraphQL over REST for an API, and what does GraphQL make harder?”
What this tests
- The problem GraphQL solves: over/under-fetching for many client shapes
- Its costs: caching, N+1 resolvers, query complexity, authorisation per field
- REST strengths: HTTP caching, simplicity, CDN-friendliness
- Decision by client diversity and team shape, not fashion
Answers by level
Read the beginner answer first and notice what is missing.
GraphQL solves a specific problem: many different clients (web, iOS, a partner integration) need different shapes of the same data, and with REST you either over-fetch, under-fetch and make several round trips, or maintain a bespoke endpoint per screen. A single typed schema with client-selected fields removes that. It fits a product with several front ends owned by different teams and a data graph with real depth.
It makes several things harder. HTTP caching is gone: every query is a POST to one URL, so CDN and browser caches do nothing without extra work (persisted queries, GET with hashed ids). Resolvers naively produce N+1 queries — a list of 50 orders each resolving customer is 51 queries — so you need batching (DataLoader) from day one. Arbitrary queries mean arbitrary cost, so you need depth and complexity limits and per-field authorisation. Error handling is 200 with an errors array, which confuses monitoring built on status codes.
REST remains the better default for a public API with simple resources, for anything that benefits from CDN caching, and for a single client owned by the same team as the backend, where the "many shapes" problem does not exist.
Green flags · Red flags
- Names over/under-fetching across many clients as the problem GraphQL solves
- Lists the costs: lost HTTP caching, N+1, query cost, per-field auth, 200-with-errors
- Knows DataLoader and persisted queries as the standard mitigations
- Keeps REST for public APIs and cacheable resources
- Decides by client diversity and ownership
- "GraphQL is more efficient than REST."
- Unaware of the N+1 resolver problem
- Thinks GraphQL replaces the need for an API gateway or authorisation
- Would expose an unrestricted GraphQL endpoint publicly