Do We Need GraphQL?

> In the world of GraphQL, HTTP is an unfortunate transport mechanism rather than something to be embraced. Rather than using the standard semantics, we ignore them completely by treating HTTP like a dumb pipe.

Yep, this seems to be the nub of it. Whether this is good or bad depends on your perspective. On one side, REST is about transferring representations of particular objects. If you're in the graph query world, you're not looking at things an object at a time. So maybe side-stepping what HTTP provides in order to build a higher-level abstraction is good, and HTTP should just be a dumb pipe.

On the other hand, HTTP has this entire world of primitives you can use, and treating it like a dumb pipe throws away many years of software and architecture advances, in order for HTTP to provide something that really any transport could probably just as easily.

If graph query really catches on, we'll have to deal with the mismatch between what graph query is trying to do, and what HTTP was built to do.

Personally as far as graph query goes, I'm partial to the Cypher query language (https://neo4j.com/developer/cypher-query-language/); I'd like a true declarative query language rather than a way of shoe-horning similar ideas into a JSON format. But if the web goes in a direction of making any kind of graph query more easy and available, that's not going to be a loss as far as I'm concerned.