Technically correct. The worst kind of correct.
GraphQL arrived in 2015 promising to fix over-fetching, under-fetching, and the tyranny of rigid endpoints. A decade later, the industry has quietly reached a verdict: for most systems, REST was never the problem.
The performance case for GraphQL has eroded significantly. HTTP/2 and HTTP/3 multiplexing eliminate the round-trip penalty that made batching queries attractive, allowing multiple REST requests to resolve in parallel over a single connection at negligible overhead. Meanwhile, GraphQL's insistence on POST semantics remains its Achilles heel — responses cannot be cached at the CDN edge, pushing load back to origin servers and adding latency that careful REST design avoids entirely.
Operationally, REST has compounded its advantages. OpenAPI 3.1 tooling now generates type-safe clients, server stubs, and living documentation from a single specification file - closing the DX gap that GraphQL once owned. Contract testing combined with semantic versioning via URL paths gives REST APIs a predictable evolution story that GraphQL's "just deprecate the field" approach struggles to match at scale.
Security posture also favours REST. GraphQL's introspection feature, enabled by default in most implementations, hands a complete schema map to anyone who asks - a reconnaissance gift that responsible teams must actively disable and monitor. Depth-limiting and query cost analysis add operational complexity that simply does not exist in REST.
GraphQL remains the right tool in specific contexts: public developer platforms serving diverse, unpredictable client shapes, or tightly integrated frontend/backend teams building product UIs at speed. But as a default architectural choice in 2026, REST - bolstered by modern HTTP transport, mature tooling, and hard-won operational simplicity — is not the legacy option. It is the considered one.