A team debates REST and GraphQL for a new public API. What should actually decide it, and what is the operational cost each one imposes?

What genuinely decides it

• Who the consumers are and how varied their needs. GraphQL earns its cost when many different clients need different shapes of the same data and the alternative is an ever-growing set of bespoke endpoints. If there are three consumers with stable needs, it is machinery without a problem.
• Whether you control the clients. GraphQL's flexibility is a liability with untrusted callers, because query cost becomes unbounded and you have created a denial-of-service surface out of a feature.
• How much caching matters. REST over HTTP gets caching for free at every layer — browser, CDN, proxy — keyed on URL. GraphQL's single POST endpoint discards all of it, and rebuilding equivalent caching inside the application is substantial work.
• The team's operational maturity. GraphQL requires query complexity analysis, depth limiting, persisted queries and per-field observability to be run safely. A team that will not build those should not expose it publicly.

The operational costs

GraphQL: complexity scoring before execution · the N+1 problem, which requires batching infrastructure and does not solve itself · per-field rather than per-endpoint observability · error semantics that return 200 with errors in the body, breaking every conventional monitoring assumption · and the difficulty of deprecating a field you cannot prove is unused without per-field telemetry.

REST: endpoint proliferation as consumers' needs diverge · over-fetching and under-fetching, which pushes clients toward multiple round trips · versioning pressure, since a change to a shared response shape affects every consumer · and the gradual accretion of query parameters that turn an endpoint into an ad-hoc query language anyway.

The answer that is often right

REST for the public API, GraphQL for first-party clients. The public surface gets stability, cacheability, predictable cost and universal tooling. Internal clients with varied needs get the flexibility, inside a trust boundary where unbounded query cost is a manageable problem rather than an attack surface.

This is not a compromise; it reflects that the two audiences have different requirements, and choosing one protocol for both optimises for whichever was louder in the design meeting.