That's true in theory, but in practice REST is a (limiting) spec for the kinds of verbs you're allowed to use between systems, and graphQL is a significant and much needed expansion of that.

GraphQL is limiting as well, just in a different way. GraphQL uses POST by default, which means you don't get browser caching.

It's a tradeoff that makes sense for Facebook. It allows them to make changes to their API without needing to version it. And they can take the hit of more requests hitting their server. For most apps though, I think the tradeoff is probably not a great one to choose.

> REST is a (limiting) spec

Nitpick but REST is not a spec to begin with. It's a set of ideas. There is absolutely no normative REST spec. Developers as of today are still debating what REST is, for better or worse. GraphQL IS a spec, like SOAP, XML-RPC ...

I agree that REST isn't a spec theoretically, but in my experience when you talk about building a Restful api you tend to be actually agreeing to use the HTTP verb spec, which is what I don't like at all.

gRPC is a much better approach.

I have, a lot, and when I could only GET kinds of hierarchical data instead of lumping nested queries, I turned to graphQL (or a, er, homegrown subset of it - it had just been announced) to fill in the gaps. It turns out that most software doesn't, really, care about asking for or updating 'state' per se, and the amount of awkward munging you have to do interpret every kind of query as 'asking about state' is, in my opinion, largely pointless.

The REST philosophy is so conceptually big that it's useless for actually building a system; what I meant by 'in practice' is that REST in practice is 'how do I stuff what I want into the http verbs and make it seem plausibly like state transfer' and that's an exercise that I can't see myself doing 'for purity' again. (in a simple app that actually is just asking about and updating state, sure, it's fine. But when you have to make ten queries for different records because you can't ask the server to join things for you dynamically, it's less fun.)

(edit: especially when you need the results to be an atomic picture of the underlying data, gathered in a transaction. Do I invent a GET resource for every tuple of values I might want to query directly? Or do I stop blindly following an architecture and do the practical thing and implement real queries? A: Always the latter.)

Again, the problems you describe with REST are a limitation of your implementation, not of REST itself. GraphQL itself is built on top of REST via a single GET/POST query endpoint.

The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]:

    /users/123?fields=name,email,work.name,work.address

where "work" is a sub-resource in the same vein as GraphQL. The difference between this and GraphQL is purely syntactic:

    user({ "id": 123 }) {
        name,
        email,
        work {
            name,
            address
        }
    }

[1] http://jsonapi.org/format/#fetching-sparse-fieldsets

GraphQL uses a single endpoint for the entire API. It would be a POST to /graphql, there would be no /users/123 resource.

GraphQL is a form of RPC, it's not REST.

When you say that GraphQL is built on top of REST, are you sure you're not mixing up REST and HTTP? Replace the hierarchical URI structure from REST with a 'novel query syntax' and all that's left is pretty much just the fact that both are ways of fetching data using HTTP methods.

Thank you, so tired to see "REST vs GraphQL" topics/blog posts. They are orthogonal.