REST vs GraphQL.
A fixed menu where each dish is a separate order, versus telling the kitchen exactly what you want on one plate.
REST is a restaurant with a fixed menu. Each dish lives at its own address (/users, /orders), and you place a separate order for each one. Simple and predictable, but if you want a bit of three dishes you place three orders, and each plate arrives whole even if you only wanted a corner of it.
GraphQL hands you a single order window where you write down exactly what you want — these fields from users, those from their orders — and it comes back on one plate. You ask once and get precisely what you asked for, no more and no less.
- One menu, fixed dishes.1
REST is a fixed menu: each dish lives at its own address — /users, /orders.
- Three orders, three trips.2
Want three dishes? You place three separate orders and wait for three trips.
- I only needed the name.3
And each plate arrives whole, even when you only wanted a corner of it.
- Just these, please.4
GraphQL hands you one order window: write down exactly the fields you want.
- One plate, exactly right.5
It all comes back on a single plate, nested data and all, in one round trip.
- Can’t cache a custom plate.6
The catch: every order is bespoke, so the easy caching REST relies on stops working.
The problems GraphQL targets
REST has two classic annoyances. Over-fetching: an endpoint returns a big object when you only wanted a name. Under-fetching: showing one screen needs data from several endpoints, so the client makes a chain of requests. On a phone over a slow network, both hurt.
GraphQL lets the client describe the whole shape it needs in one query, so it gets exactly that, in one round trip, even across related objects.
What that flexibility costs
Because every query can be different, the simple HTTP caching that makes REST fast no longer applies out of the box. The server also has to guard against expensive queries, and a naive resolver can fire one database call per item (the "N+1" problem) unless you batch carefully.
Neither wins outright. REST shines for simple, cacheable, public APIs; GraphQL shines when many clients need different, deeply-related slices of the same data.