REST vs. GraphQL – A search for evidence on which is better

Re:REST vs. GraphQL – A search for evidence on which is better by 14u2c on Tuesday December 15, 2020 @09:33PM (#25438337)

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.

[ Parent | on HN ]

Re:REST vs. GraphQL – A search for evidence on which is better by dragonwriter on Tuesday December 15, 2020 @09:55PM (#25438513)

> 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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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/

[ Parent | on HN ]

Re:REST vs. GraphQL – A search for evidence on which is better by ako on Wednesday December 16, 2020 @02:34AM (#25440023)

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.

[ Parent | on HN ]

Re:REST vs. GraphQL – A search for evidence on which is better by preommr on Tuesday December 15, 2020 @10:03PM (#25438560)

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.

[ Parent | on HN ]

Re:REST vs. GraphQL – A search for evidence on which is better by axaxs on Tuesday December 15, 2020 @09:39PM (#25438382)

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.

[ Parent | on HN ]