GraphQL revolutionized how clients consume APIs. But REST isn't dead. The choice depends on context, team, and the needs of your consumers.
REST has been the reference for twenty years for good reason: its simplicity. Resources identified by URLs, standardized HTTP verbs, a mental model every developer knows. It leverages proven foundations (HTTP caching, stateless design) and benefits from an immense ecosystem of tools. For a public API or simple internal services with few varied clients, REST remains the default choice.
GraphQL shines in contexts where clients have very different data needs. A mobile app that must minimize bandwidth, a complex frontend aggregating data from multiple sources, a product team frequently evolving their screens — in these cases, REST's overfetching and underfetching become painful. GraphQL lets the client describe exactly what it needs and receive precisely that, nothing more, nothing less.
GraphQL's trade-off is operational complexity: managing query complexity (depth limiting), harder observability, less natural caching. The N+1 problem is a classic trap without proper DataLoader configuration. An empirical rule: if you have a single frontend client you control with stable data needs, REST is sufficient. If you're exposing an API to many clients with heterogeneous needs, GraphQL is worth the investment.