REST vs GraphQL
REST vs GraphQL for API design: fewer round trips vs simpler caching, and which fits your client's actual data needs.
Last updated
The short answer
REST is simpler to build, cache and reason about, and it's the safer default for a small API with a handful of clients. GraphQL earns its extra complexity when multiple clients need different shapes of the same data and round trips are expensive — mobile apps on flaky networks, or one backend serving many different frontends.
| Dimension | REST | GraphQL |
|---|---|---|
| Endpoints | Many, one per resource | One, queries shape the response |
| Over-fetching | Common — fixed response shape | Avoided — client asks for fields |
| Caching | Free via HTTP/CDN caching | Needs custom client-side caching |
| Versioning | New endpoints or /v2 prefix | Evolve schema, deprecate fields |
| Learning curve | Low — plain HTTP verbs | Higher — schema, resolvers |
Choose REST when
- →You have one client or a few similar ones, and each screen needs roughly the response the endpoint already returns.
- →You want HTTP caching (CDNs, browser cache, ETags) to just work without extra infrastructure.
- →Your team is small and the extra machinery of a schema and resolver layer isn't worth it yet.
Choose GraphQL when
- →Different clients — web, iOS, a partner integration — need meaningfully different slices of the same underlying data.
- →Round trips are expensive and stitching together several REST calls per screen is the actual problem you're solving.
- →The API is large enough that a typed schema and introspection genuinely help client developers move faster.
The catch nobody mentions
GraphQL moves the N+1 query problem from 'obviously your fault' to 'hidden inside a resolver' — a naive resolver that fetches each field's data separately can issue hundreds of database queries for one GraphQL request, and it looks fine until real traffic hits it. Batching (DataLoader or equivalent) isn't optional, it's the price of admission.