4 ms·

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, d

by axaxs 6y ago

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.

charrondev 6y ago
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.
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.
ako 6y ago
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.
Aeolun 6y ago
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.

by axaxs 6y ago

charrondev 6y ago

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.

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.

ako 6y ago

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.

Aeolun 6y ago

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.