The mobile order screen needs a status, a total and a delivery date. The web portal also needs change history, discounts and refunds. The API team proposes one large response for both. Client teams would rather stop transferring unwanted data — and stop opening tickets whenever they need a different combination of fields.
GraphQL often enters the conversation at that point. It lets the client specify which data to request. But the business problem is not the absence of GraphQL. It is the time and money spent coordinating ordinary changes between the frontend and the backend.
Two ways to agree on the response
A conventional REST API exposes resources and operations: get an order, list orders, change a shipping address. The server team defines the response contract in advance. It may still support filtering, specialised representations and carefully designed endpoints. REST does not require awkward APIs.
GraphQL describes available types and fields in a schema. A client can request an order's total, status and recipient name without asking for every other field. Resolvers can gather that data from several internal systems.
It is misleading to call REST inflexible and GraphQL contract-free. Both have contracts. GraphQL simply lets clients compose more combinations from the exposed graph, with a corresponding increase in the possible queries the server must support.
When flexibility shortens delivery
Imagine a product with several fast-moving interfaces. Every screen needs a different view, and the API team has become a queue for small response changes. GraphQL may remove some of that coordination: clients can select fields that already exist in the schema without waiting for another endpoint.
But if the delay is in a business rule — whether a paid order may be refunded, for instance — GraphQL will not decide that rule. The owning product team still has to define and implement it.
For a stable partner integration, REST's predictability may be more useful: explicit operations, established documentation and straightforward use of HTTP caching. A partner consuming a few resources for years may have no need to compose arbitrary selections.
Who pays for one flexible request?
One request over the network does not necessarily mean cheap work on the server. An innocent-looking GraphQL query can traverse many relationships and trigger numerous calls to internal dependencies. Teams need limits on query depth and cost, response sizes, resolver behaviour and visibility into the operations actually being executed.
REST can suffer from expensive request chains too, especially when clients assemble a screen through repeated calls. But the cost of a fixed endpoint is often easier to predict and constrain. Measure actual latency and backend work rather than choosing a technology by counting arrows in a presentation.
Authorisation matters even more. In GraphQL, clients select fields that they may or may not be entitled to read. Authenticating the user at a shared endpoint is not sufficient: domain logic must enforce permissions for the actual order and data being requested. The official GraphQL authorisation guide recommends keeping those rules in the business layer.
Questions I would test with real screens
Take several actual mobile, web and partner journeys. Which fields are used? Which calls are unnecessary? How often do client teams wait for a contract change? Who owns the complete response today?
If the problem is mainly fetching data from too many internal services, API Composition or a Backend for Frontend may solve it without exposing a flexible data graph.
And someone must own query limits, schema evolution and the removal of obsolete fields years later. Flexibility is an operational responsibility, not a free product feature.
I would choose GraphQL when it removes a measurable coordination problem between client and server teams — not because selecting arbitrary fields makes for a better-looking demo. Without that problem, a simple REST API can be the better investment.