You'll end up inventing your own ad-hoc GraphQL that way. For example, GraphQL supports this, trivially: query User { user(id: "123") { id na

You'll end up inventing your own ad-hoc GraphQL that way. For example, GraphQL supports this, trivially: query User { user(id: "123") { id name topPosts(limit: 10) { id, title } drafts: comments(published: false) { id, body } friends { id photo(size: "100x100") { url, width, height } } newestPosts(since: "3days", categories: ["news", "chat"]) { id, title forum { id, name } creator { id, photo(size: "100x100") { url, width, height } } } } latestNews(limit: 10) { title, url } } All one query. Selecting a subset of attributes is a small part of GraphQL. (gRPC also allows you filter fields, but doesn't have structured querying.) GraphQL is a protocol and a schema language, not an ORM. It's a way to provide a common interface on top of any implementation. For example, in the above query, users could be in the backend's own database, whereas "friends" could be something stored in a completely different backend. The GraphQL server could trivially act as a façade that federated/aggregated the results of both. I would argue that GraphQL fulfills the objectives (or at least desired features) of REST much better than what has been delivered thus far. For example, REST's hypermedia aspect ("HATEOAS") has not been widely adopted — because discoverability is poor and there's no standard protocol for introspecting a schema. But look around and you can easily find a dozen different GraphQL clients (my personal favourite being Prisma's GraphQL Playground [1]) that can be pointed at any GraphQL-compliant server to run queries and browse the schema. Those that criticize GraphQL generally don't seem to realize how simple it is, and how close it's still to the REST style of consuming and producing JSON. [1] https://github.com/prisma/graphql-playground https://github.com/prisma/graphql-playground