REST vs. GraphQL
Resource-based endpoints vs. a single, client-specified query endpoint.
REST structures an API as a set of resource-based endpoints, each returning a fixed shape of data. GraphQL exposes a single endpoint where clients specify exactly which fields they need in each query. The core trade-off is flexibility and precision (GraphQL) vs. simplicity and cacheability (REST).
REST
Best for
- Public APIs where HTTP caching (CDNs, browser cache) matters
- Simpler APIs where client needs don't vary much across consumers
- Teams wanting simpler tooling and a lower learning curve
Trade-offs
- Over-fetching (getting more data than needed) or under-fetching (needing multiple requests) is common as client needs diverge
- Versioning (v1, v2) is a manual, ongoing concern as the API evolves
GraphQL
Best for
- APIs serving multiple, different clients (web, mobile, third-party) with different data needs
- Complex, deeply nested data where a client would otherwise need many REST round-trips
- Teams wanting a strongly-typed schema as a contract between frontend and backend
Trade-offs
- Standard HTTP caching doesn't work out of the box — needs its own caching strategy
- A single expensive query can be harder to reason about and rate-limit than fixed REST endpoints
- More setup and tooling investment than a REST API needs
| Dimension | REST | GraphQL |
|---|---|---|
| Endpoints | Many, resource-based | Single endpoint, query-based |
| Over/under-fetching | Common as needs diverge | Solved by design — client asks for exactly what it needs |
| HTTP caching | Works out of the box | Needs a dedicated caching layer |
| Learning curve | Lower | Higher — schema design, resolvers |
Verdict
REST remains the simpler, more broadly applicable default, especially for public APIs and CDN-cached content. GraphQL earns its added complexity when you have multiple genuinely different client types pulling different shapes of data from the same backend.