REST vs GraphQL
Both let a client talk to a server over HTTP. REST models resources as URLs with standard verbs; GraphQL exposes one endpoint and a query language where the client asks for exactly the fields it wants. The real choice is about who controls the shape of the response.
| Dimension | REST | GraphQL |
|---|---|---|
| Shape of response | Server decides per endpoint | Client asks for exact fields |
| Over/under-fetching | Common (fixed payloads) | Avoided by design |
| Number of endpoints | Many (one per resource) | One (/graphql) |
| HTTP caching | Native & easy (GET + URLs) | Harder (POST, needs extra work) |
| Learning curve | Low — everyone knows it | Higher — schema, resolvers, N+1 |
| Tooling / discovery | OpenAPI, mature ecosystem | Introspection, typed clients |
Pick REST when
Public APIs, simple CRUD, when HTTP caching and cache-friendly CDNs matter, or when you want the lowest team ramp-up. REST is the boring, reliable default.
Pick GraphQL when
Rich clients pulling nested data from many sources, mobile apps that must minimise round-trips, or many front-ends with different data needs served by one schema.
Verdict
Default to REST — it is simpler, cache-friendly and universally understood. Reach for GraphQL when the pain of over-fetching and multiple round-trips is real and recurring, and you can afford the extra server complexity (schema design, resolver performance, N+1 handling).