REST vs GraphQL Is a Judgment Test, Not a Loyalty Test

Everyone on your team has a strong opinion about REST vs GraphQL, and half of them picked their side in 2019 and never looked back. Here is the war story version: a product page ships, it fires four REST requests to render, the mobile team complains about battery drain, someone "fixes" it by merging everything into one 2MB endpoint, and now every client pays for fields it never reads. Three rewrites later, the frontend team has PTSD and the backend team has trust issues.

The interview version of this is simpler and crueler. "REST or GraphQL?" is not a loyalty test. It is a judgment test. An interviewer can tell in ten seconds whether you actually chose the contract for a reason, or whether you just memorized a blog post.

Why it matters more than the framework debate people obsess over: the API contract is the one decision your frontend cannot escape. You can swap a component library in a weekend. You cannot swap your data-fetching contract without touching every screen. Pick wrong and you pay for it in round trips, in over-fetching, and in the kind of performance bugs that only show up on cheap phones your team never tests on.

The non-obvious angle nobody mentions in interviews: the real cost is rarely bandwidth. It is ownership. GraphQL gives the client query power, which sounds like freedom, until you realize someone has to own query complexity, rate limiting, and cache invalidation for arbitrary queries. REST gives you predictable endpoints, until the fifth client-specific "v2" endpoint exists and nobody knows which ones are safe to kill. The failure mode of GraphQL is a query that quietly costs your database a full-table scan. The failure mode of REST is endpoint sprawl. Pick the failure mode your team is equipped to govern, because you will get the failure either way.

Here is the decision rule, copy-paste friendly. Run any API through these three checks:

1. Client diversity. One web app that you control? REST is probably fine. Web, iOS, Android, and a partner API, all needing different slices of the same data? That is GraphQL territory.
2. Graph tangles. If rendering one screen means five sequential round trips for nested data, you have a graph problem and you are solving it with HTTP duct tape. Name the round-trip count out loud in the interview; it is the number that does the talking.
3. Cost ownership. Who pays when the contract is wrong? Over-fetching burns mobile data plans and CDN bills. Under-fetching burns users on 3G. GraphQL kills over-fetching but moves the cost to query governance. REST is cheap to start and expensive to evolve.

The punchline I give in every interview: name the cost or do not spend it. "GraphQL because our three clients need different data shapes and we are willing to own query complexity" is a staff-level answer. "GraphQL because REST is old" is a junior answer with senior confidence.

I broke this down in 40 seconds here: REST vs GraphQL: How Staff Engineers Choose (Q14/60)