REST: the default choice and why it remains good
REST has been the dominant API architecture for over 15 years. It is well-understood, extensively tooled, cacheable by HTTP infrastructure, and easy to document with OpenAPI. For the majority of APIs — including most public APIs and internal services — REST is the correct choice.
REST works particularly well when: - Your resource model is relatively simple and predictable - Clients have similar data needs (not a dozen different clients with very different query patterns) - HTTP-level caching provides significant performance benefits - Your team is more familiar with REST than GraphQL - You need a public API that third parties will consume
GraphQL: when client flexibility matters
GraphQL solves a specific problem: the over-fetching and under-fetching that occurs when many different clients (web app, mobile app, partner integration) each need slightly different shapes of data from the same service.
With REST, supporting different clients often means either creating client-specific endpoints (resource explosion) or returning a superset of data and letting clients ignore what they do not need (bandwidth waste). GraphQL lets each client specify exactly what data it needs in a single query.
GraphQL works particularly well when: - You have multiple clients with significantly different data requirements - Your data model has complex relationships that clients need to traverse (user → orders → products → reviews) - You want a single endpoint that evolves as client needs change, without versioning - Frontend teams want autonomy over the data they fetch without backend changes
The real cost of GraphQL
GraphQL's flexibility comes with genuine cost:
Query complexity and performance
GraphQL's expressive queries can lead to expensive database operations if not carefully managed. N+1 query problems require DataLoader or similar batching patterns to resolve. Complex nested queries can hit the database in ways that a well-designed REST endpoint would not.
Caching complexity
HTTP caching works naturally with REST (GET /products/123 can be cached by CDNs and browser caches). GraphQL queries all hit the same POST /graphql endpoint, making HTTP-level caching impossible without client-side caching solutions (Apollo Client, urql).
Authorisation complexity
With REST, you can apply middleware to specific routes. With GraphQL, you need field-level authorisation that checks permissions for every field a client might request. Getting this wrong means data leakage.
The pragmatic answer
For most projects, start with REST. It is simpler, better-tooled, and sufficient for most use cases. Add GraphQL when you have demonstrated that the specific problem it solves (flexible multi-client queries) is actually a problem for your application — not because GraphQL is theoretically elegant.