[donpark]

GraphQL has nothing to do with SQL and a lot to do with addressing problems associated with choppy nature of REST in practice.

In essence, GraphQL query is a grocery list of stuff you want. Response is a grocery bag of what you wanted.

From REST perspective, GraphQL is a union of multiple REST query URLs presented as JSON hierarchy, turning each path fragment into a nested object.

[Touche]

GraphQL is always POST, no? It's not REST at all. It's not quite RPC either. There's a single handler for all API requests. I don't know if there's a name for this type of thing.

[delluminatus]

GraphQL is a query language. It's protocol-independent. It just so happens that HTTP POST is a convenient way to deliver queries. Instead of using an HTTP endpoint, you could just as correctly implement GraphQL directly over TCP, or messaging queues, or whatever you want.

[srigi]

True, but when implementing GraphQL on top of webserver (like Express.js in article), correct HTTP methods should be adopted - GET for querying, POST for mutations. I don't see any harm in doing that.

[Touche]

Sure, but the manor it is going to be used in real life is HTTP POST, 99% of the time. This is the use-case it is trying to solve, after all.

[schrockn]

I think given the current state of the spec that's pretty accurate. However we really view GraphQL as the way that front-ends/client specify their data requirements. One way of fulfilling that is to dispatch the queries to the server as is. However if you view this as an API to data, which can include client software, this can get a lot more interesting, and allows you to use different transports, messaging protocols, etc

For example on iOS we used GraphQL to transition our persistence from Core Data to a propriety (client) storage engine.