> This looks like an effort to bring to REST APIs some of the benefits GraphQL offers, mainly by adding extensive conventions on top of traditional HTTP endpoints.

This was my take-away as well. There are a couple of full-featured frameworks in GraphQL land -- Hasura[0] and Prisma[1] spring to mind, among others -- that enforce conventions and in exchange allow you to specify a sort_by array and operate on a standardized payload without exposing too much non-essential configuration.

---

[0] https://hasura.io/all-features

[1] https://www.prisma.io/with-graphql

I must admit the main thing that puts me off GraphQL is that it's not built on JSON. Maybe that's silly, but it just seems like a move away from what we know and love. Also the graphql tools seem to be based around the idea of a fixd schema, and I'm looking for something a little more flexible.

The schema is not defined in json, which is good, json can't have comments. Graphql requests and responses are json, and you can get a json representation of the schema using the introspection api.

I for one do not like json, the only formats I can think of that I like less are xml and yaml. I'd prefer a protocol with a binary implementation, it must support comments, I like type annotations, and a schema language would be great.

I've been working with Amazon's ion lately and I've enjoyed it. It has text and binary representations, fields have types (in binary), it can be represented as json (you lose annotations)

> move away from what we know and love

I didn't get the memo where we decided that we love JSON.

Sure, but there are tradeoffs to consider: JSON may be difficult and inconvenient to use for human interaction, but on the other hand it's also really slow for machine reading and writing. Plus you have the added bonus of it being an inefficient use of bandwidth.

Especially when there are almost consensual better alternatives https://hjson.org

Uhh, no. Part of the reason JSON is useful is that it's easy to write a correct parser in comparison to most other things - adding a bunch of the complexity of YAML back to JSON seems a bad idea. This makes it possible to use JSON as a serialisation layer for network protocols without introducing too much additional risk of parsing-related vulnerabilities.