The real question isn't which is newer — it's who should control the shape of a response: the server, or the client calling it.
REST models an API as resources — /orders/42, /users/7/orders — fetched and modified with standard HTTP verbs, where the server decides exactly what shape each endpoint returns. GraphQL models an API as a single typed schema behind one endpoint, where the client writes a query naming exactly the fields it wants, nested however it needs them. Both are ways to expose the same backend; the difference is who's in the driver's seat on response shape, and that choice has real consequences for caching, versioning, and how many round trips your app makes.
REST's biggest advantage is one most teams stop noticing: a GET request is cacheable by URL, for free, at every layer between your server and the user — browser, CDN, reverse proxy. No extra infrastructure, no query hashing, it just works because it's built into HTTP itself. Add a mature ecosystem — every language has solid HTTP tooling, every engineer already understands status codes and verbs — and REST stays the lowest-friction way to expose a straightforward set of resources.
It also fails predictably. A resource-per-endpoint design means the failure modes are well understood: an endpoint returns too much (over-fetching a mobile client doesn't need) or a screen needs data from three endpoints (under-fetching, solved by three round trips or a bespoke aggregation endpoint). Those are annoying, not mysterious — and for APIs with one client and a stable set of screens, they rarely justify a different architecture.
GraphQL exists to solve exactly the over/under-fetching problem above. One endpoint, one schema, and the client asks for precisely the fields a screen needs — a mobile app can request a thin slice of a user object while a web dashboard requests the full graph, from the same API, in a single round trip each. That matters most when several clients with different data needs share a backend, or when a UI is nested and relational enough that assembling it from REST calls means chaining requests based on each other's results.
The schema is also the API contract, enforced and introspectable — tools like GraphiQL or codegen read it directly, so client and server can't drift silently the way a REST API's implicit shape sometimes does. The trade is real, though: caching isn't free anymore, the backend needs a resolver layer (and batching via something like DataLoader to avoid its own N+1 problem), and an unbounded query lets a client ask for arbitrarily deep, expensive data unless you add query complexity and depth limits yourself.
You're exposing a fairly stable set of resources to one primary client, or building a public API where free HTTP/CDN caching matters.
Your team wants the simplest possible mental model and the widest tooling support, with minimal new infrastructure.
Screens map cleanly to one or two resources — there's no real nested-data assembly problem to solve.
Multiple clients — web, mobile, partner integrations — need genuinely different slices of the same data.
Screens are relational and nested enough that REST would mean chaining several requests to assemble one view.
You're aggregating several backend services into one graph for frontend teams, and can invest in resolver-layer batching and query limits.
Not inherently. GraphQL cuts round trips and stops over-fetching, but a poorly optimized resolver layer introduces its own N+1 query problem on the backend. Speed comes from how it's implemented, not from the architecture itself.
Yes. A GraphQL layer such as Apollo Server can sit in front of existing REST endpoints or microservices as a backend-for-frontend, aggregating them into one graph without touching the underlying services.
Mostly, for additive changes — new fields can be added without breaking existing clients, and old fields are deprecated in place instead of shipping a new API version.
It stops being free. REST's GET requests cache naturally at the HTTP and CDN layer by URL. GraphQL typically posts to one endpoint, so caching needs deliberate work — persisted queries, a normalized client cache like Apollo or Relay, or a CDN keyed on the query and variables.
REST, for the simpler mental model and mature tooling. Reach for GraphQL once multiple client types or genuine over-fetching become a measured problem, not a theoretical one.
Microservices solve problems most teams don't have yet. When the boring architecture is the right one — and the signals it's time to split.
Read the guideYour content management choice shapes your frontend architecture more than most teams expect going in.
Read the guide