Re:REST vs. GraphQL – A search for evidence on which is better
by 14u2c on Wednesday December 16, 2020 @02:20AM
(#25439944)
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.
Re:REST vs. GraphQL – A search for evidence on which is better
by dragonwriter on Wednesday December 16, 2020 @09:33AM
(#25442921)
> 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/
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.