Ask which API style you should use and you'll get answers with the emotional intensity of a religious debate. GraphQL evangelists will tell you REST is a legacy relic. REST loyalists will tell you GraphQL is complexity cosplay. Both camps are arguing about the wrong thing — because the right choice almost never depends on which technology is "better." It depends on the shape of your data, the shape of your clients, and the shape of your team.

Here's a framework for deciding based on your actual situation instead of the loudest blog post.

What each one is actually good at

Strip away the tribalism and the core difference is simple.

REST gives you a set of URLs, each returning a fixed, server-defined shape of data. /users/42 returns a user. /users/42/orders returns their orders. The server decides what each endpoint contains; the client takes what it's given. This is predictable, cacheable by default, and trivially understood by anyone who's used the web.

GraphQL gives you a single endpoint and a query language. The client describes exactly the data it wants — these fields from the user, those fields from each of their orders, nested however it likes — and gets back precisely that shape in one round trip. The power moves to the client.

That single distinction — who decides the response shape — drives almost everything else.

The problems GraphQL was built to solve

Two specific pains push teams toward GraphQL, and if you don't have them, you don't need it.

Over-fetching and under-fetching. With REST, an endpoint returns a fixed payload. A mobile screen that needs only a user's name and avatar still downloads their full profile — bio, settings, timestamps, the works (over-fetching). Meanwhile, a screen that needs a user plus their last three orders plus each order's status has to hit three endpoints and stitch the results together client-side (under-fetching). GraphQL collapses both problems: ask for exactly the fields you need, across exactly the relationships you need, in one query.

Many diverse clients evolving fast. If you have a web app, an iOS app, an Android app, and a partner integration — each needing a different slice of the same data, each shipping on its own schedule — REST tends to sprout either bloated do-everything endpoints or a proliferation of bespoke ones. GraphQL lets each client self-serve from a single schema without the backend cutting a new endpoint every sprint.

If those two paragraphs describe your life, GraphQL is earning its complexity. If they don't, keep reading.

The problems GraphQL quietly introduces

GraphQL isn't free. It moves complexity rather than removing it, and the new complexity lands in places that are easy to underestimate.

Caching gets harder. REST rides on a decade of HTTP caching infrastructure — CDNs, browser caches, ETags — all keyed on URLs. GraphQL's single POST endpoint defeats most of that out of the box. You get caching back, but you build it yourself at the application or client layer, and it's real work.

Performance footguns multiply. The flexibility that lets a client ask for deeply nested data also lets it ask for expensive deeply nested data. The infamous N+1 query problem — one query fanning out into hundreds of database calls — is a constant hazard, and you'll need tools like DataLoader-style batching and query-cost analysis to keep it contained. A naive GraphQL server is a denial-of-service vulnerability waiting for a curious client.

Observability and security need new habits. Every REST endpoint is a natural unit for rate limiting, monitoring, and access control. With one GraphQL endpoint, you have to reconstruct all of that at the field and query-cost level. It's doable and well-trodden, but it's a different mental model your whole team has to learn.

The decision framework

Forget which is trendier. Walk these questions in order.

1. How many clients consume this API, and how different are their data needs?
One client, or several with near-identical needs → REST. Multiple clients with genuinely divergent, fast-changing needs → GraphQL starts paying off.

2. How relational and nested is your data?
Mostly flat resources fetched independently → REST fits naturally. Deeply connected graphs where clients routinely need "this, plus its related that, plus their related other thing" → that's literally what GraphQL is named for.

3. How much does HTTP caching matter to you?
Public, cacheable, read-heavy content (think a content site or product catalog) → REST's free CDN caching is a serious advantage. Highly personalized, per-user data that wasn't going to cache well anyway → you lose less by going GraphQL.

4. What does your team already know?
This one is underrated. A team fluent in REST that adopts GraphQL for a CRUD app will spend its first quarter relearning caching, error handling, and performance tuning it already had for free. Technology you can operate confidently beats technology that's theoretically optimal.

5. Do you actually have the GraphQL pains today?
Not "might we someday." Today. If you're over-fetching badly or drowning in client-specific endpoints right now, that's a real signal. If you're choosing GraphQL for a problem you're imagining, you're buying complexity on credit.

The answer nobody wants to hear

For a large share of products — a single app talking to a backend, mostly straightforward resources, a small team — REST is the right call, and it's not close. It's simpler to build, simpler to cache, simpler to secure, and simpler to hire for. "Boring" is a feature when it's load-bearing.

GraphQL is a genuinely excellent answer to a specific set of problems: many clients, deeply relational data, and rapid independent evolution. When you have those problems, it's transformative. When you don't, it's a sophisticated solution looking for a question.

And you're not locked in. Plenty of mature systems run REST for their cacheable public surface and GraphQL for their complex internal client needs. The two aren't enemies — they're tools with different sweet spots, and the senior move is matching the tool to the shape of the work rather than to the shape of the argument.

Pick the one your situation is asking for. Let everyone else fight about it online.