GraphQL and REST are not competing standards — they are different tools for different problems. REST has been the dominant API paradigm for over a decade, and it remains excellent for many use cases. GraphQL, developed by Facebook and open-sourced in 2015, solves specific problems REST handles poorly. Understanding when each shines — and when each struggles — prevents you from choosing based on hype rather than fit.
How REST Works
REST APIs expose resources at fixed endpoints. GET /users/123 returns a user. GET /users/123/orders returns their orders. Each endpoint returns a predetermined data structure. The server decides what data to include in each response. This simplicity is REST's greatest strength — it is easy to understand, easy to cache, and well-supported by every programming language and framework.
REST struggles with two scenarios: over-fetching (endpoints return more data than the client needs) and under-fetching (the client needs to make multiple requests to assemble the data for a single view). A mobile app that needs a user's name and their latest three orders might need to hit two endpoints and discard most of the returned data.
How GraphQL Works
GraphQL provides a single endpoint where clients send queries specifying exactly what data they need. The client describes the shape of the response, and the server returns precisely that shape — nothing more, nothing less. This eliminates both over-fetching and under-fetching. A single GraphQL query can traverse relationships and return nested, related data in one round trip.
GraphQL also provides a strongly typed schema that serves as a contract between client and server. This schema is introspectable — tools can automatically generate documentation, TypeScript types, and client-side code from it.
When to Choose REST
- Simple CRUD APIs: If your API primarily creates, reads, updates, and deletes resources with straightforward data shapes, REST's simplicity wins.
- Public APIs: REST's simplicity makes it more accessible to third-party developers. Most public API consumers expect REST.
- Heavy caching needs: HTTP caching works naturally with REST endpoints. GraphQL requires more sophisticated caching strategies since all requests go to a single endpoint via POST.
- File uploads: REST handles file uploads natively. GraphQL requires workarounds or separate upload endpoints.
When to Choose GraphQL
GraphQL excels when multiple clients (web, mobile, third-party) consume the same API with different data needs, when your data model has complex relationships that require joining data across entities, when minimising network requests matters (mobile apps on slow connections), or when you want a self-documenting, typed API contract. Headless CMS platforms and eCommerce storefronts are natural GraphQL use cases.
The Pragmatic Approach
You do not have to choose one exclusively. Many successful architectures use REST for simple services and GraphQL as a gateway layer that aggregates data from multiple REST backends. At Born Digital, we evaluate each project's data complexity, client diversity, and team experience before recommending an API strategy. The best API is the one that makes your specific application simpler to build and maintain.