REST vs GraphQL
REST is the dominant convention for HTTP APIs, while GraphQL is a query language that lets clients request exactly the data they need. Both power production APIs at scale, but they suit different team structures and frontend needs.
Updated June 2024Resource-based HTTP APIs with predictable conventions
A query language for your API
Pros
- Universally understood; every developer knows GET, POST, PUT, DELETE without onboarding
- HTTP caching, CDN integration, and browser tools work naturally with REST endpoints
- Easier to version and evolve with v1, v2 URL prefixes or header negotiation
- No special client library required; any HTTP client can consume a REST API
- Simpler performance story: endpoint-level caching is straightforward to implement
Cons
- Over-fetching returns more data than the client needs on most requests
- Under-fetching forces multiple round trips to assemble a single screen of data
- No enforced schema means documentation can drift from the actual API behavior
Best for
- Public APIs consumed by diverse third-party clients
- Simple CRUD services where resource boundaries are clear
- Teams that prioritize broad compatibility and minimal client friction
Pros
- Clients request exactly the fields they need, eliminating over and under fetching
- Strong schema enforced at the server and validated at query time
- Single endpoint simplifies mobile development by removing multi-request waterfalls
- Introspection enables tooling like GraphiQL and automatic SDK generation
- Ideal for aggregating multiple backend services behind a unified frontend API
Cons
- Caching is more complex because every query is a POST to the same endpoint
- N+1 query problem requires DataLoader or similar batching solutions
- Higher learning curve and operational overhead for teams new to the query language
Best for
- Mobile apps where bandwidth and round trips are expensive
- Frontend teams that want autonomy over their data fetching without backend changes
- API gateways that aggregate multiple downstream services into one schema
When to use which
Public API for third-party developers to integrate
REST's universality means third-party developers can integrate with any language or framework using only standard HTTP tooling, with no GraphQL client library required.
Mobile app needing data from 5 backend services
GraphQL aggregates all five services behind one schema and one request, reducing mobile round trips and eliminating over-fetching on constrained connections.
Internal dashboard with many different data views
GraphQL lets frontend developers query exactly the fields each dashboard widget needs without waiting for backend engineers to create or modify dedicated endpoints.
Webhook receiver and event notification API
Webhooks push data over standard HTTP POST. REST conventions match this pattern naturally, while GraphQL subscriptions add unnecessary complexity for push-only flows.
Verdict
REST is the right default for public APIs, simple services, and teams where HTTP caching and broad client compatibility matter most. GraphQL pays off when you have multiple frontend clients with divergent data needs, when bandwidth is constrained, or when a frontend team frequently waits on backend endpoint changes to ship new screens.