What’s the best rest vs graphql approach for our api to avoid breaking clients?

[MatthewRR]

I’m trying to decide between using a RESTful design or switching to GraphQL for our new service API, and I’m stuck on how to handle future changes without breaking existing clients. The flexibility in querying sounds great, but I’m worried about the complexity of implementing things like caching and rate limiting compared to what we’re used to.

[Tyler_J]

We flirted with GraphQL after REST, but the complexity of caching and rate limiting felt heavier in practice. We kept a REST path with versioned endpoints and a separate GraphQL surface until we could ship stable fields; the deprecation plan helped.

[MasonW]

I’m not sure the problem is changing the API at all; it might be tooling and how you monitor usage. We overestimated the need for perfect query flexibility and spent weeks building custom per field caches that nobody used.

[SophiaSB]

Do you need real-time subscriptions, or is read and write enough?

[JerryC]

Sometimes the blocker was not the API style but how we ship changes; a solid deprecation window and clear client communications did more to prevent breakage than choosing REST or GraphQL.