REST vs GraphQL: which one fits your project?

REST vs GraphQL debates tend to turn into architecture tribalism, which is not useful when you are actually deciding what to build. Both are mature, well-supported approaches — the right one depends on your data shape, your client types, and your team, not which is trendier.

How they differ, concretely

REST exposes fixed, resource-based endpoints and leans on standard HTTP semantics, which makes it easy to cache at the CDN level. GraphQL exposes a single endpoint where the client specifies exactly the shape of data it needs in one request, avoiding both the over-fetching and the under-fetching that REST can produce when a screen needs data from several resources at once.

Where REST still wins

Simplicity, broad tooling support, and the ability to cache aggressively at the HTTP/CDN layer make REST the better default for straightforward CRUD APIs, public APIs with predictable consumers, and teams that want the lowest possible learning curve.

Where GraphQL earns its complexity

GraphQL pays off when the frontend needs complex, nested data from multiple resources in a single view — a dashboard pulling from several data sources is the classic case. It also helps when you have several very different client types (a mobile app and a web app with different data needs) served from one backend, and when reducing round-trips matters on slower networks.

A simple decision framework

Simple CRUD, a public API, or a small team new to API design — choose REST. Complex nested queries, multiple frontends with different data shapes, or a fast-moving frontend team that wants to query flexibly without backend changes — GraphQL earns its overhead. Many products end up mixing both: REST for simple resources, a GraphQL layer where aggregation genuinely helps — which is how most of our own API and integration work ends up shaped.

The caching asymmetry is the part worth understanding before you commit, because it is structural rather than a matter of effort. HTTP caching keys on the request method and URL, so REST gets shared caches, CDN edges and conditional requests essentially for free. GraphQL sends most operations as POSTs to a single endpoint, which those layers cannot cache — so equivalent caching has to be rebuilt inside the application. The GraphQL project documents this openly rather than hiding it, and points at persisted queries and per-field caches as the answer.

What GraphQL costs you to run safely

The comparison usually stops at the query language, but the operational bill is where the two really separate. A REST endpoint has a roughly knowable worst case: it does one thing, and you can rate-limit it by URL. A GraphQL endpoint accepts queries nobody on your team wrote, so its worst case is whatever a stranger can compose — and OWASP’s guidance is blunt that the controls for this are not built in.

Concretely, that means four pieces of work REST never asks for. Depth limiting, which GraphQL has no native support for, so you have to add it yourself. Query cost analysis, assigning a cost to resolving each field so an expensive query can be refused before it runs. Defences against batching and aliasing abuse, where many object requests collapse into a single call that can enumerate users, emails and IDs while looking like one innocent request to your rate limiter and your WAF. And turning introspection off in production, which OWASP recommends system-wide for anything publicly reachable. None of these is hard alone. Together they are a body of work that belongs in the estimate, not something discovered afterwards.

Sources

The technical behaviour described above is taken from these primary specifications and docs, checked August 2026. The operational security guidance is OWASP’s. The decision framework is ours.

• GraphQL — Learn GraphQL ↗

  The official introduction: a single endpoint, client-specified response shape, and the project’s own documentation of caching and query-complexity as the areas needing deliberate design.

• GraphQL Foundation — GraphQL Specification ↗

  The normative spec behind the type system, schema introspection and execution semantics — the reason GraphQL tooling is consistent across implementations.

• MDN Web Docs — HTTP caching ↗

  How shared and private caches key on method and URL, and why that makes cacheability close to free for REST-style GETs and manual work for a single POST endpoint.

• RFC 9110 — HTTP Semantics ↗

  The standard defining the method semantics, status codes and conditional requests that REST leans on rather than reinventing.

• OWASP — GraphQL Cheat Sheet ↗

  Depth limiting has no native GraphQL support and must be added; query cost analysis assigns costs per field; batching and aliasing can enumerate objects while slipping past rate limits and WAFs; introspection should be disabled system-wide in production.