3 ms·

There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. When using REST e

by 14u2c 6y ago

There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. When using REST endpoints you are at the mercy an API's documentation, which is often quite poor. I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL.

axaxs 6y ago
That's a good point as API doc is often very, very wrong. Still, this could just as easily be added as some semi standardized REST extension/spec. Granted, it wouldn't have the traction up front GQL gives you.
dragonwriter 6y ago
> There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. So, commonly, does a REST endpoint that observes HATEOAS (without which it is not REST.) > I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL. REST is an architectural style, not a standard, but it is baked into the description of the architectural style.
- 14u2c 6y ago
  Of course you can build these elements into your own implementation, but there is value in a higher level standard that has these items guaranteed. If a product advertise a GraphQL api you know immediately there will be no trouble with determining what the api can return and accept.
  - dragonwriter 6y ago
    > Of course you can build these elements into your own implementation, but there is value in a higher level standard that has these items guaranteed. That's what OpenAPI is. (You mention the Swagger tool, but claim it's not baked into “the standard” the way GraphQL is; as well as a tool, Swagger was also the name of the standard, though the current version of that standard is called OpenAPI.) It is also what JSON:API is. It is also what OData is. It is also what RAML is. Heck, there's a good argument that it is what GraphQL is, too: https://hasura.io/blog/rest-view-of-graphql/ https://hasura.io/blog/rest-view-of-graphql/
preommr 6y ago
I am pretty sure there's something about REST that makes it so that it's easy to discover what resources are available. I just pulled up Fielding's paper and couldn't find anything, but wikipedia has a reference to 'Hypermedia as the engine of application state' (HATEOAS). But then again, I am not sure anyone actually writes systems like this. Very few people actually write REST systems and instead make REST-like APIs.
ako 6y ago
OData (which is REST) can return the schema and much more: $metadata resource describes all entities, operations, relations, and can also contain documentation, capabilities, etc.

by 14u2c 6y ago

axaxs 6y ago

That's a good point as API doc is often very, very wrong. Still, this could just as easily be added as some semi standardized REST extension/spec. Granted, it wouldn't have the traction up front GQL gives you.

dragonwriter 6y ago

> There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. So, commonly, does a REST endpoint that observes HATEOAS (without which it is not REST.) > I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL. REST is an architectural style, not a standard, but it is baked into the description of the architectural style.

14u2c 6y ago
Of course you can build these elements into your own implementation, but there is value in a higher level standard that has these items guaranteed. If a product advertise a GraphQL api you know immediately there will be no trouble with determining what the api can return and accept.
- dragonwriter 6y ago
  > Of course you can build these elements into your own implementation, but there is value in a higher level standard that has these items guaranteed. That's what OpenAPI is. (You mention the Swagger tool, but claim it's not baked into “the standard” the way GraphQL is; as well as a tool, Swagger was also the name of the standard, though the current version of that standard is called OpenAPI.) It is also what JSON:API is. It is also what OData is. It is also what RAML is. Heck, there's a good argument that it is what GraphQL is, too: https://hasura.io/blog/rest-view-of-graphql/ https://hasura.io/blog/rest-view-of-graphql/

preommr 6y ago

I am pretty sure there's something about REST that makes it so that it's easy to discover what resources are available. I just pulled up Fielding's paper and couldn't find anything, but wikipedia has a reference to 'Hypermedia as the engine of application state' (HATEOAS). But then again, I am not sure anyone actually writes systems like this. Very few people actually write REST systems and instead make REST-like APIs.

ako 6y ago

OData (which is REST) can return the schema and much more: $metadata resource describes all entities, operations, relations, and can also contain documentation, capabilities, etc.