[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.