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

Re:REST vs. GraphQL – A search for evidence on which is better by silisili on Tuesday December 15, 2020 @06:21PM (#25436778)

Same. But I'm also getting old and cranky. Every advantage typically pointed out over REST could easily be solved in REST. You can do joins in REST people, don't be afraid! I often would add query params for such common things, such as (fake example) fillChildren=true to have what is essentially a parent object populated with its child object in what would normally be separate calls.

[ Parent | on HN ]

Re:REST vs. GraphQL – A search for evidence on which is better by Aeolun on Wednesday December 16, 2020 @07:19AM (#25441697)

Of course you can do that. But eventually keeping up with all the different fill parameters is going to catch up to you.

Besides, what do you call the parameter to fill the owner of the children? Fillchildrenowners? It’s nicer to work with if your API takes this into account.

[ Parent | on HN ]

Re:REST vs. GraphQL – A search for evidence on which is better by charrondev on Tuesday December 15, 2020 @08:41PM (#25438008)

At work almost every endpoint supports an “expand” parameter that will do various expansions of referenced resources in the returned records. This can:

- cause additional sql joins - or pull individual records from a cache (if it’s a small enough dataset) - or cause one additional DB query and save a network round trip.

Example:

/api/v2/discussions?sort=recent&expand=insertUser,updateUser,lastCommentUser,parentCategory

This would be a pretty extensive case but is very useful.

[ Parent | on HN ]

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 ]

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

True, and this also something OData has as part of the standard. Using a standard way to do this has big benefits, as this knowledge can be implemented in tools (BI, ETL, low-code dev), which can then support many REST endpoints.

[ Parent | on HN ]