REST
An architectural style using resource URLs and HTTP methods.
Simple, cacheable with HTTP, widely understood; clients may over- or under-fetch.
Backend & APIs
REST exposes many resource URLs with fixed responses; GraphQL exposes one endpoint and a typed schema where the client asks for exactly the fields it needs.
An architectural style using resource URLs and HTTP methods.
Simple, cacheable with HTTP, widely understood; clients may over- or under-fetch.
A query language and runtime for APIs with a typed schema.
One request fetches nested data in the shape the client asks for; needs care with N+1 queries, caching and query cost.
| Aspect | REST | GraphQL |
|---|---|---|
| Endpoints | Many | One |
| Response shape | Server decides | Client decides |
| HTTP caching | Easy | Harder (POST, per query) |
| Typing | Optional (OpenAPI) | Built-in schema |
| Best for | Simple public APIs | Complex UIs with nested data |
REST exposes many resource URLs, each returning a shape the server decides, using HTTP methods for actions. GraphQL exposes one endpoint with a typed schema, and each client query specifies exactly which fields it needs, often across related objects in one request.
Over-fetching is receiving more fields than the screen needs; under-fetching is needing several requests to gather related data. GraphQL avoids both by letting the client select fields and nested relations in one query.
REST works naturally with HTTP caching: GET URLs, Cache-Control and ETags on CDNs and browsers. GraphQL usually sends POST requests to one URL, so caching moves to the client (normalised caches) or needs persisted queries with GET.
For simple, resource-oriented APIs, public APIs consumed by many clients, file uploads and downloads, and when HTTP caching and widely understood conventions matter more than query flexibility.
When many clients such as web, iOS and Android need different shapes of deeply related data, when the UI changes often, or when one gateway should unify several backend services behind a typed schema.
REST has no built-in schema; teams describe APIs with OpenAPI. GraphQL requires a schema of types, queries, mutations and subscriptions that both validates requests and documents the API.
REST uses HTTP status codes such as 404 or 422 per request. GraphQL usually returns 200 with an errors array beside partial data, so clients must check errors in the response body.
Resolving a list and then a field per item can trigger one database query per item. DataLoader batches and caches these lookups per request, turning N+1 queries into a few.
REST APIs often version in the URL or headers (v1, v2). GraphQL evolves one schema by adding fields and deprecating old ones, since clients only receive fields they ask for.
Both need authentication and authorisation. GraphQL also needs protection against expensive queries: depth limits, query cost analysis, persisted queries and rate limiting by cost, since one request can ask for a lot.
Practise every comparison in your dashboard.
Start learning