4 ms·

It's also not that hard to implement attribute filtering with REST endpoints. People make a big deal about being able to control the shape of your API responses

It's also not that hard to implement attribute filtering with REST endpoints. People make a big deal about being able to control the shape of your API responses with GraphQL, but this completely achievable with standard REST APIs as well.

tshaddox 4y ago
Sure, you could have a syntax for requesting (potentially recursive) nested resources in the query string of a REST API, and there are some systems that do something close [0], but if you do it’s probably a less friendly syntax than GraphQL and has all the same problems as GraphQL regarding performance and rate limiting. [0] A very simple convention for including nested resources in a JSON API: https://www.jsonapi.net/usage/reading/including-relationships.html https://www.jsonapi.net/usage/reading/including-relationship... A totally cool but kinda over the top library that exposes a REST API over your database with a very GraphQLesque query string syntax that supports recursively nested resource inclusion, filtering, etc.: https://postgrest.org/en/stable/api.html#nested-embedding https://postgrest.org/en/stable/api.html#nested-embedding
- ryanbrunner 4y ago
  99% of the time you don't need to be recursive though. Field filtering with 1 level of expansion for related resources solves 95% of problems for you, and if you're implementing something on your own API, you can have a custom route for the 5%. GraphQL falls into the same trap that a lot of things do IMO - it assumes that because 5% of things are complex, that you need a solution that can deal with that complexity for 100% of your API, which needlessly complicates everything else.
- ec109685 4y ago
  Agree with this. We created our own nested query language using matrix params and path separators to let the client query for nested sub-resources, including filters against collections. It’s pretty neat but nice graphql standardized it so things like consoles and other tools can be written against it.
- krainboltgreene 4y ago
  > Sure, you could have a syntax for requesting (potentially recursive) nested resources in the query string of a REST API Or you could just make an endpoint that gives you the data you want.
  - imtringued 4y ago
    That endpoint has to be unique for the client, otherwise someone else could abuse this API and when you filter out an attribute the rogue user depends on, you break their application.
    - krainboltgreene 4y ago
      No it doesn't. It's just a GET request with a parameter or two. People make this stuff so hard when it doesn't need to be.
- user_of_the_wek 4y ago
  Reminds me of http://odata.org/ http://odata.org/

tshaddox 4y ago

Sure, you could have a syntax for requesting (potentially recursive) nested resources in the query string of a REST API, and there are some systems that do something close [0], but if you do it’s probably a less friendly syntax than GraphQL and has all the same problems as GraphQL regarding performance and rate limiting. [0] A very simple convention for including nested resources in a JSON API: https://www.jsonapi.net/usage/reading/including-relationships.html https://www.jsonapi.net/usage/reading/including-relationship... A totally cool but kinda over the top library that exposes a REST API over your database with a very GraphQLesque query string syntax that supports recursively nested resource inclusion, filtering, etc.: https://postgrest.org/en/stable/api.html#nested-embedding https://postgrest.org/en/stable/api.html#nested-embedding

ryanbrunner 4y ago
99% of the time you don't need to be recursive though. Field filtering with 1 level of expansion for related resources solves 95% of problems for you, and if you're implementing something on your own API, you can have a custom route for the 5%. GraphQL falls into the same trap that a lot of things do IMO - it assumes that because 5% of things are complex, that you need a solution that can deal with that complexity for 100% of your API, which needlessly complicates everything else.
ec109685 4y ago
Agree with this. We created our own nested query language using matrix params and path separators to let the client query for nested sub-resources, including filters against collections. It’s pretty neat but nice graphql standardized it so things like consoles and other tools can be written against it.
krainboltgreene 4y ago
> Sure, you could have a syntax for requesting (potentially recursive) nested resources in the query string of a REST API Or you could just make an endpoint that gives you the data you want.
- imtringued 4y ago
  That endpoint has to be unique for the client, otherwise someone else could abuse this API and when you filter out an attribute the rogue user depends on, you break their application.
  - krainboltgreene 4y ago
    No it doesn't. It's just a GET request with a parameter or two. People make this stuff so hard when it doesn't need to be.
user_of_the_wek 4y ago
Reminds me of http://odata.org/ http://odata.org/