REST vs GraphQL: What's Actually Different, in Plain English

REST and GraphQL both move data between a client and a server over HTTP, and both commonly return JSON — which is part of why the actual difference between them gets muddled in a lot of surface-level explanations. The real distinction isn't about speed or modernity; it's about who decides what shape the response takes. In REST, the server decides — each endpoint returns a fixed, predetermined structure. In GraphQL, the client decides — a single endpoint accepts a query describing exactly which fields are needed, and the server returns precisely that, nothing more, nothing less.

How REST actually works

A REST API exposes a set of distinct endpoints, each representing a resource — `/users/42`, `/users/42/orders`, `/products/17` — and each endpoint returns a fixed response shape defined by the server, regardless of whether the client needs every field in that response or just one. Getting a user's name and their most recent order might require two separate requests to two separate endpoints, and each of those responses might include several fields the client has no actual use for in that specific screen — a well-known pattern called over-fetching.

How GraphQL actually works

GraphQL exposes a single endpoint, and instead of hitting different URLs for different resources, the client sends a query describing exactly which fields it needs, potentially spanning what would have been multiple REST endpoints in one request — a user's name and their most recent order's total, in a single round trip, with no extra fields included that weren't explicitly asked for. This solves over-fetching directly, and it also solves under-fetching (needing to make several sequential REST calls to assemble one screen's worth of data), since a single GraphQL query can describe a nested shape spanning multiple related resources at once.

The trade-offs — because there genuinely are trade-offs

• REST is simpler to cache using standard HTTP caching (since each distinct resource has its own stable URL), while GraphQL — using a single endpoint for everything — needs its own caching strategy layered on top rather than relying on plain HTTP caching.
• REST's fixed responses are easier to reason about and debug from the browser's network tab; GraphQL's flexible queries mean the exact response shape varies request to request, which can take more effort to trace.
• GraphQL genuinely reduces over- and under-fetching, which matters more the more complex and interrelated the data being fetched is — a simple API with a handful of straightforward resources may not gain much from GraphQL's added complexity.
• REST has a much longer track record and simpler tooling to get started with; GraphQL has a steeper initial learning curve (schema definitions, resolvers) before the benefits show up.

When REST is the better fit

A simpler API with a small number of relatively independent resources, a team already comfortable with conventional REST tooling, or a situation where standard HTTP caching (CDN-level caching by URL, for instance) matters a lot are all cases where REST's simplicity is a genuine advantage rather than a limitation to work around. Introducing GraphQL's added complexity for a straightforward CRUD API often isn't worth the overhead it brings.

When GraphQL is the better fit

An application with deeply interrelated data, multiple client types (a web app and a mobile app, say) that each need a genuinely different subset of the same underlying data, or a situation where over-fetching and under-fetching are causing real, measurable performance problems in a REST setup are the cases where GraphQL's flexibility earns its added complexity. It's also worth noting the two aren't strictly exclusive — some systems run a GraphQL layer in front of existing REST services rather than replacing REST outright.

Common misconceptions

• "GraphQL is always faster" — it can reduce the number of round trips and unnecessary fields, but a poorly designed GraphQL schema can introduce its own performance problems (like the well-known N+1 query issue) that a simpler REST endpoint wouldn't have.
• "REST is outdated" — it isn't; it remains the dominant choice for a huge share of production APIs and is genuinely the simpler, more appropriate option for plenty of use cases.
• "You have to pick one for an entire system" — a GraphQL layer sitting in front of existing REST services, or REST and GraphQL coexisting for different parts of the same system, are both common patterns.

The short version: REST returns a fixed, server-defined response shape per endpoint; GraphQL lets the client specify exactly which fields it needs from a single endpoint. REST is simpler and easier to cache with standard HTTP tooling; GraphQL reduces over- and under-fetching at the cost of more setup complexity. Neither replaces the other universally — the right choice depends on how interrelated your data is and how much request-shape flexibility your clients actually need.