REST is a broad term - there's nothing to stop REST apis from doing all those things with HATEOAS, discoverable apis, json schemas, etc. The real advantage of GraphQL is the distillation and combination of preexisting ideas into a coherent spec and toolchain with a mainstream advocate, rather than a loose collection of standards, conventions, and libs with no mainstream advocacy.

To be fair, I feel like this fact means GraphQL does sit at a higher level of abstraction than "vanilla REST", which does make them not-so-comparable.

> REST is a broad term - there's nothing to stop REST apis from doing all those things with HATEOAS, discoverable apis, json schemas, etc.

This fact should be emphasized. REST is just an architectural style, and it's absurd to claim that an architectural style bars developers from implementing specific functionalities.

It's even more absurd to compare a very specific implementation of a specific interface with an architectural style used to design and implement interfaces.

It seems to me that this whole GraphQL vs REST debate has absolutely nothing to do with REST or even HTTP APIs, and is actually a discussion about how reusing a ready-made solution developed by third-parties has some advantages over having to roll your own.

Adhoc querying of multiple resources and REST are not incompatible, see e.g. oData. It basically offers the same functionality as GraphQL, but also follows all the Restfull http best practices.

You can see some oData examples here: https://www.odata.org/getting-started/basic-tutorial/#reques...

> Adhoc querying of multiple resources and REST are not incompatible, see e.g. oData.

This.

Sometimes I wonder if graphql proponents either are unaware of established REST strategies and tooling or if they intentionally turn a blind eye .

In terms of ease of building a query (and resulting ease of comprehension of that query) that will give you the exact response structure you want from the client-side, the two are not comparable, there is no blind-eye turning in this regard as far as I can tell.

But I'd love to see an REST-based GraphiQL equivalent to prove this wrong: https://github.com/graphql/graphiql

That's REST + oData, not REST. GraphQL includes adhoc querying in the standard.

Otherwise I could claim ISAM is just like a SQL database because MySQL is a SQL database built on top of ISAM.

No, not REST + oData. oData is an http protocol which conforms to all of the REST best practices (url is identifier of a resource, use of http operations, use of http error codes, providing links to other resource, payload contains a representation of state).

AFAIK, oData only lets you request a single entity type at a time, doesn't it? For example, in the example you provided, would it be possible to fetch a collection of People and Airports as part of the same request? What would that request look like?

You can include associated entities by using expand, e.g. order with orderlines. See: https://www.odata.org/getting-started/basic-tutorial/#expand

The oData contract, $metadata, describes an entire domain model, including associations between entities. You can use expand to join entities over these associations.

You can request multiple queries in one http operation using batch requests: https://www.odata.org/getting-started/advanced-tutorial/#bat...

No, you can query a collection of these entities and get back the resulting set with pagination.

No, you can batch requests.

The question was not about batching, it was about join queries over more than one resource type.

I guess I should be more clear...

batch means you can do things like combine these:

GET /serviceRoot/Airports GET /serviceRoot/People

into one request (and get the results in one response)

I believe that's what the poster was asking.

Here's a link to a different example from the OData site: https://www.odata.org/getting-started/advanced-tutorial/#bat...

You're using the word "join". I'm not sure if you meant that in a relational sense or not. If yes, then maybe you're wondering if you can get airports with their related people, or people with their related airports in one request with OData. Again, the answer is yes.

Thanks for the explanation!

No problem... I realize my initial answer was pretty useless. "batch" has a specific meaning in Odata but of course you wouldn't know that unless you already knew Odata.