Overview
REST models your API as resources (/users/123) with HTTP verbs and is dead simple to cache and reason about. GraphQL gives the client a query language to fetch exactly the data it wants in one round trip, which kills over-fetching and the "N endpoints for N screens" problem — at the cost of more server complexity and harder caching.
REST vs GraphQL: key differences
| REST | GraphQL | |
|---|---|---|
| Shape | Many endpoints, fixed responses | One endpoint, client-specified fields |
| Over/under-fetching | Common | Avoided by design |
| Caching | Easy (HTTP/CDN) | Harder (POST, custom layer) |
| Versioning | Explicit (/v2) | Evolve the schema, deprecate fields |
| Tooling | Universal | Strong typed schema + introspection |
When to use REST
Public APIs, simple CRUD, when HTTP caching/CDNs matter, or when you want maximum interoperability and minimal server complexity.
When to use GraphQL
Rich clients (mobile/SPA) hitting many resources per screen, rapidly-evolving frontends, or aggregating several backends behind one typed graph.
Verdict
REST is the simpler default and caches beautifully. Reach for GraphQL when clients need flexible, deeply-nested data from many sources and over-fetching is a real cost — accepting the extra caching and server complexity.
Common questions
Is GraphQL better than REST?
Not universally. GraphQL wins for flexible client-driven data fetching; REST wins for simplicity, HTTP caching and public APIs. Many systems expose both.
Does GraphQL replace a database?
No. GraphQL is an API layer; it still reads from your databases/services via resolvers.