REST vs GraphQL: How to Actually Choose

The short answer: choose REST by default — it's simpler, cacheable over plain HTTP, and understood by everyone and everything. Reach for GraphQL when your clients need wildly different slices of a richly-connected data graph and you're tired of either over-fetching or building a dozen bespoke endpoints. GraphQL solves a real problem; it also adds real complexity, so adopt it because you have that problem, not because it's newer.

"REST or GraphQL?" gets argued like a sports rivalry, but it's just a tradeoff with a fairly clear answer once you know what each is actually optimising for. Here's the framework I use to decide, without the hype on either side.

What each one is really solving

REST models your API as resources at URLs, manipulated with HTTP verbs. Its superpower is that it leans on HTTP itself: status codes, caching, CDNs, and every tool ever built all understand it for free. Its weakness is the shape of responses — each endpoint returns a fixed payload, so clients often over-fetch (get fields they don't need) or under-fetch (make several round-trips to assemble one screen).

GraphQL gives the client a query language to ask for exactly the fields it wants, across related objects, in a single request. Its superpower is eliminating over- and under-fetching for complex, interconnected data. Its cost is everything that moves off HTTP: caching gets harder (it's usually one POST to /graphql), you need a schema and resolvers, and you inherit a new class of problems like query depth limits and the N+1 resolver trap.

The questions that make the decision

Run your project through these. The weight of the answers points clearly one way.

1. How connected is your data, and how varied are your clients? One web app hitting a handful of endpoints → REST is plenty. A graph of users ↔ posts ↔ comments ↔ tags consumed by web, iOS, Android, and partners each wanting different slices → GraphQL earns its keep.

2. Is HTTP caching important to you? If a CDN or browser cache in front of GET endpoints is a big part of your performance story, REST keeps that for free. GraphQL's single POST endpoint means you rebuild caching at the application layer.

3. How many teams/clients consume the API? GraphQL shines when many independent clients evolve at different speeds — each queries what it needs without you shipping a new endpoint. For a single first-party client, that flexibility is mostly unused complexity.

4. What's your team's appetite for operational overhead? GraphQL brings a schema, resolvers, query-cost analysis, and persisted-query/security concerns. That's worth it at scale and overkill for a CRUD app.

5. Do you need the HTTP ecosystem's defaults? Idempotency, status codes, range requests, standard auth middleware — all native to REST, all things you re-implement or map awkwardly in GraphQL.

A reasonable default, and the honest middle ground

For most projects — a product with one or two first-party clients and moderately-connected data — start with REST. It's less to run, trivially cacheable, and every hire already knows it. You can always add GraphQL later for the surface that genuinely needs it (lots of teams run both: REST for simple resources and public APIs, GraphQL for the complex internal graph).

And whichever you pick, the API quality basics are identical and matter more than the paradigm: consistent response shapes, actionable errors, real pagination, sane versioning. I wrote the whole wishlist from the consuming side in what frontend devs wish backend APIs did differently — a thoughtful REST API beats a sloppy GraphQL one every day, and vice versa.

The takeaway

GraphQL isn't "better than REST"; it's a different trade. It buys precise, flexible fetching for diverse clients over connected data, and pays for it in caching and operational complexity. If you have that fetching problem, the trade is great. If you don't, REST's simplicity is the feature. Choose for the problem in front of you, not the one on the conference slides.