REST vs GraphQL: The Real Difference (and When to Use Each)
REST and GraphQL both move data between client and server — but they trade off in opposite ways. Here's the honest comparison and how to choose.
Both REST and GraphQL are ways for a front-end to ask a server for data. They're not good-versus-bad; they're two philosophies that trade off in opposite directions. Understanding that trade-off makes the choice obvious.
REST: many endpoints, fixed shapes
In REST, the server exposes endpoints — URLs like /users/42 and /users/42/orders — each returning a fixed shape of data. It's simple, it maps cleanly to HTTP, and it caches beautifully (each URL is a cacheable thing). The downside: the server decides the shape, so you often get more than you need (over-fetching) or have to call several endpoints to assemble one screen (under-fetching).
GraphQL: one endpoint, you choose the shape
GraphQL flips it. There's usually one endpoint, and the client sends a query describing exactly the fields it wants:
{
user(id: 42) {
name
orders(last: 3) { total }
}
}The server returns precisely that — no more, no less, in a single round trip. For a complex screen pulling from many sources, this is a genuine win. The cost: caching is harder (it's all one endpoint), and the server is more complex to build and protect against expensive queries.
REST puts the server in charge of the response shape; GraphQL hands that control to the client.
How to choose
| Choose REST when… | Choose GraphQL when… |
|---|---|
| Simple, stable data needs | Complex, nested data per screen |
| HTTP caching matters a lot | Many clients with different needs |
| Small team, fast start | Front-end wants to move independently |
| Public, widely-consumed API | Rich product UI, mobile + web |
Most teams should start with REST — it's less to get wrong — and reach for GraphQL when over/under-fetching genuinely hurts. Whichever you pick, knowing your HTTP status codes still matters.
Key takeaways
- REST: many fixed endpoints, simple, cache-friendly.
- GraphQL: one endpoint, client picks exact fields, fewer round trips.
- GraphQL fixes over/under-fetching but complicates caching.
- Start with REST; adopt GraphQL when data needs get complex.
Frequently asked questions
Is GraphQL replacing REST?
No. REST is still the default for most APIs and is simpler to build, cache and debug. GraphQL shines for complex, data-hungry front-ends. Plenty of teams use both.
What is over-fetching and under-fetching?
Over-fetching is when a REST endpoint returns more data than you need; under-fetching is when one endpoint isn't enough so you make several calls. GraphQL's main pitch is solving both by letting the client specify exactly what it wants.