The REST vs GraphQL war isn't over, but it's evolved. A few years ago, if you mentioned GraphQL in the wrong chat, you'd get strong opinions. By 2021, the dust has settled on something more useful than religious preference: a set of practical criteria for when you should actually use each one. Neither is right for everything, and that's okay.
REST's enduring strengths
REST with HTTP/JSON is the universal language of web services. Every language, framework, and tool can produce and consume REST APIs. HTTP caching (GET requests, ETag, Cache-Control) is built in. REST errors have predictable shapes (status codes). The operational tooling, API gateways, WAFs, rate limiters, reverse proxies, is designed around HTTP semantics. For public APIs that need to be consumed by diverse clients over the internet, REST is the right default.
When GraphQL improves on REST
GraphQL outperforms REST for: applications with multiple clients that need different data shapes from the same backend, schemas that evolve frequently (adding fields to GraphQL types is backwards compatible; changing REST response shapes breaks clients), and complex, interconnected domain models where REST would require many round trips to fetch related data. Mobile applications and SPAs with diverse data requirements are the strongest GraphQL use case.
gRPC for internal services
gRPC with Protocol Buffers is the right choice for internal service-to-service communication where both client and server are controlled by the same team. The performance advantages (binary serialisation, multiplexed HTTP/2) are meaningful at high call volumes. The .proto contract prevents breaking changes from reaching production silently. The limitation is browser incompatibility, gRPC requires grpc-web for browser clients.
The API gateway as the unifying layer
In a polyglot backend, an API gateway can expose a REST or GraphQL interface to clients while routing to a mix of REST, gRPC, and GraphQL upstream services. Kong, AWS API Gateway, and Azure API Management provide this translation capability. The tradeoff is an additional hop in every request and the operational complexity of managing the gateway layer.