REST and GraphQL get framed as a rivalry more often than they deserve. Each is a better fit for different shapes of problem, and the choice should come from what’s consuming the API, not which one is trending.
When REST is the better fit
REST remains the simpler, more predictable option for APIs with a clear resource model — users, orders, products — especially when caching matters, when the consumers are varied (web, mobile, third-party integrations), or when the team maintaining it is more comfortable with conventional HTTP semantics. It’s also easier to document and debug with standard tooling.
When GraphQL earns its complexity
GraphQL pays off when a front end needs to pull together data from many different sources in a single request, when different clients (a mobile app and a web dashboard, say) need very different shapes of the same underlying data, or when over-fetching on REST endpoints has become a genuine performance problem. It costs you more setup — resolvers, schema design, caching strategy — so it’s worth that cost specifically when the flexibility solves a real problem.
The honest answer
Most products don’t need GraphQL’s flexibility, and adding it preemptively just adds a second technology for the team to maintain. Start with REST unless there’s a specific, current pain point — fragmented data fetching across many screens — that GraphQL is actually solving today, not one you’re predicting for later.