4 ms·

Click bait title. They really are quite different in very significant ways and not exactly comparable. For example GraphQL APIs allow for ad hoc querying of mul

Click bait title. They really are quite different in very significant ways and not exactly comparable. For example GraphQL APIs allow for ad hoc querying of multiple resources and have a typed query language. Not that RESTful APIs can't do the same, but that's why they aren't really comparable. Interesting wrapper nonetheless.

ako 8y ago
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/#requestData https://www.odata.org/getting-started/basic-tutorial/#reques...
- geezerjay 8y ago
  > 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 .
  - allover 8y ago
    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 https://github.com/graphql/graphiql
- napoleond 8y ago
  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?
  - jmull 8y ago
    No, you can batch requests.
    - wsy 8y ago
      The question was not about batching, it was about join queries over more than one resource type.
      - jmull 8y ago
        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/#batch 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.
        wsy 8y ago
        Thanks for the explanation!
        jmull 8y ago
        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.
  - jbreiding 8y ago
    No, you can query a collection of these entities and get back the resulting set with pagination.
  - ako 8y ago
- ben509 8y ago
  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.
  - ako 8y ago
    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).
micimize 8y ago
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.
- geezerjay 8y ago
  > 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.

ako 8y ago

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/#requestData https://www.odata.org/getting-started/basic-tutorial/#reques...

geezerjay 8y ago
> 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 .
- allover 8y ago
  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 https://github.com/graphql/graphiql
napoleond 8y ago
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?
- jmull 8y ago
  No, you can batch requests.
  - wsy 8y ago
    The question was not about batching, it was about join queries over more than one resource type.
    - jmull 8y ago
      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/#batch 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.
      - wsy 8y ago
        Thanks for the explanation!
        jmull 8y ago
        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.
- jbreiding 8y ago
  No, you can query a collection of these entities and get back the resulting set with pagination.
- ako 8y ago
ben509 8y ago
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.
- ako 8y ago
  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).

micimize 8y ago

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.

geezerjay 8y ago
> 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.