That seems to be how most people do it in the wild if they don't have any reason to try to stick with a pure REST/HATEOAS API. Frequently when people say they d

That seems to be how most people do it in the wild if they don't have any reason to try to stick with a pure REST/HATEOAS API. Frequently when people say they do "REST" that can mean as little as "we use different HTTP verbs for the same endpoint to distinguish between calls rather than putting those verbs in URLs" (e.g. POST to a collection rather than to a route "/new", DELETE to a resource rather than POST to a route "/delete"). GraphQL was developed at Facebook and Facebook has a massive backend API used by many different teams for many different purposes. In this scenario the trade-offs were apparently worth it because purpose-built endpoints for each feature were likely not scalable and would have required deep knowledge of the full stack to implement. In teams of 1-10 people with an API that serves a single app controlled by the same team, I'm not convinced GraphQL adds much apart from adding a layer of complexity to the architecture.