The choice between REST and GraphQL is usually framed as modern against traditional, which is the least useful way to decide anything. They address different problems. GraphQL exists because some clients need to request varying shapes of data and cannot wait for a backend team to add an endpoint each time. Where that is not your situation, most of what it costs you buys nothing.
The problem it genuinely solves is client diversity. Several clients - web, iOS, Android, partners - each needing different fields and different depth from the same underlying data, on their own release schedules, will otherwise produce either an endpoint per view or over-fetching everywhere. A single flexible query interface is a real answer to that, and teams in that position generally do not regret adopting it.
The cost is that several things REST receives from HTTP for free must now be built. Caching is the clearest example: distinct URLs let intermediate caches and browsers do useful work without being asked, whereas one endpoint receiving arbitrary queries needs a caching strategy of its own. Rate limiting by request count stops meaning anything when a single request can be arbitrarily expensive, so you end up costing queries instead. None of this is insurmountable, and all of it is work you would not otherwise do.
Authorisation is where teams underestimate the difference most. In REST an endpoint has a purpose, and you can reason about who may call it. In a graph, a caller can traverse from an object they are allowed to see to one they are not, through a relationship nobody considered, so permission checks have to live on fields and edges rather than on entry points. Getting that wrong is not a performance problem, it is a data exposure.
The N+1 query pattern arrives by default and has to be actively prevented. A nested query that reads innocuously asks for a list and then a related object for each item, and the naive resolver issues one database query per element. Batching layers exist and work well, but they are a dependency the team must understand, and the failure mode is a query that behaves fine against three test records and becomes unusable against three thousand real ones.
A conventional REST interface remains the better default for a single first-party client and a team that has not solved these problems before. It is easier to cache, easier to log and debug with ordinary tools, easier to secure, and considerably easier for a new engineer to reason about. Choosing it is not conservatism, it is declining to pay for flexibility you cannot currently use.
The two are not exclusive, and the pragmatic answer is frequently both. Serve a REST interface for the straightforward, high-volume, cacheable paths, and add a query interface where a client genuinely needs to compose. What does not work is adopting a query layer across an entire system for consistency, then rebuilding caching, rate limiting and authorisation to get back to roughly where you started.
