4 ms·

It might be a clean API but it was developed to solve a problem that nobody besides huge companies like Netflix have to the detriment of REST API design and a c

by LunaSea 11y ago

It might be a clean API but it was developed to solve a problem that nobody besides huge companies like Netflix have to the detriment of REST API design and a clean network protocol. You are also bound to use both their client-side AND server-side libraries which locks you completely in.

jeswin 11y ago
REST is inadequate even for smaller companies, when it comes to the use cases Relay+GraphQL (or Falcor) tries to solve. 1. Under fetching and over fetching. 2. REST is great for CRUD, but not everything is that simplistic. Eg: Changes spanning multiple entities with transaction support. 3. Patchy PATCH support. Also, endless debates on whether something should be a PATCH or a PUT or a POST. The answer in some of those cases was that it couldn't be solved with clean REST. (Edit: added GraphQL)
- LunaSea 11y ago
  Do you have use cases that won't fit in a REST design ? I'm genuinely curious because as a web developer most of the problems I have encountered can be solved with API versioning, filters, paginations, scopes (limiting returned fields) and hierarchical URL structures (e.g: /users/:userId/comments/:commentId).
  - jeswin 11y ago
    Let me use the example you have. 1. Clean RESTful URLs like the one you have doesn't make it easy to fetch { article, article.author.name, [user.comments.commenter] } in a _single call_. GraphQL let's you define the Shape you want. 2. Updates spanning multiple resources aren't a good fit for a Resource Oriented pattern like REST. a) How do you delete multiple comments (Ids 1, 34, 44) in one shot? http://stackoverflow.com/questions/7511195/rest-architecture-for-multiple-deletes http://stackoverflow.com/questions/7511195/rest-architecture... 3. How do I edit /users/200 and /users/201 in one single call? Imagine a Grid with a Save Button. Also, this could be a transaction as well. The above is doable with REST, but it is kind of a grey area and loses some of the obviousness seen in clean URLs such as in your example.
    - LunaSea 11y ago
      I agree that those cases would be tough to make work in a "clean" or at least standard RESTful API design but it's really improbable to encounter them. 1. This issue could be attributed to the database schema design imo. 2. In what case would you want to delete multiple comments at the same time ? I'm not trying to argue for the sake of arguing but I've genuinely never had to remove parts of an array that were not either a single element or the whole array. 3. Again I don't see a scenario where you would have to do this. If it's a consequence of another API call for example: You DELETEd a "group" so all of its member "users" should be deleted too. Than this kind of side effects or consistency CRUD should be handled inside the DELETE API call of the "group". I don't think that REST API design pretends to answer every single business logic use case but it does answer most of the common ones. In my opinion it's also dangerous to use a library that will abstract those difficult / unconventional use cases because they will feel easy to solve and hide the inherent complexity and cost that is present in the Database queries.
      - efdee 11y ago
        Case for point 2: Comment administration page. You get a list of comments with checkboxes, check the ones you want to select and then click "Delete selected". Case for point 3: Like he said, a grid (with inline editing) and a "save" button.
        LunaSea 11y ago
        3. If you have a grid you also have pagination which eliminates the possibility of editing multiple rows in the same call.
        colin_jack 11y ago
        I've put some thoughts below with references to cookbook recipes, I'm not saying they are in sweet point for a lovely resource oriented design but they are things you can handle. 1. Recipe 2.4 is one option. Alternative might be granular resources, if the characteristics of your use case means they can be done efficiently. For example we might include the URL to author details inside the article. That means another request, but if those author details are made immutable (as in change to author details means new URL), then they can be given a long cache period. Also HTTP/2 will mean more granular resources have different performance characteristics. 2. Recipe 11.10 could work so the URL would be the comments collection as a whole, I'd use PATCH (or POST if PATCH isn't an option) to then send the updates you need. So a PATCH to /<posturl>/comments with the result body including information that causes those comments to be deleted. 3. Same idea as 2, I'd use PATCH to the collection or a custom resource.
- colin_jack 11y ago
  1. I think though you'd really want to have some measurements regarding the performance impact of things like over fetching. Also remember that having a resource oriented design and working well with HTTP gives you out of the box advantages in terms of caching and validation, and in HTTP/2 you get extra efficiency advantages (e.g. lots of more granular resources can be retrieved over a single connection). 2. There are patterns for that though, often best approach is to represent that transaction as a resource. Restful Web Services Cookbook covers approaches for these sorts of bulk operations. 3. Not sure that's an argument against going resource oriented, if you don't find the debate interesting just ignore it.
- Touche 11y ago
  > REST is inadequate even for smaller companies, when it comes to the use cases Relay+GraphQL (or Falcor) tries to solve. Maybe it's slightly harder to implement those things in REST, but REST gives you HTTP caching and that's a killer feature. If you'd prefer to re-invent caching so you can use POST everywhere be my guest.
- unoti 11y ago
  > Also, endless debates on whether something should be a PATCH or a PUT or a POST. An often overlooked technique for handling such arguments is to quit bickering and get back to work solving the business problems.
picardo 11y ago
Anyone who builds APIs that talk to microservices has this problem, not just huge companies. As for the lock in, working in this paradigm would be impossible without a smart client library. Similarly, GraphQL has Relay. But Falcor's client side library is much more flexible than Relay, which is only a wrapper around React apps. If you have a non-React project, you have to use Falcor.

by LunaSea 11y ago

jeswin 11y ago

REST is inadequate even for smaller companies, when it comes to the use cases Relay+GraphQL (or Falcor) tries to solve. 1. Under fetching and over fetching. 2. REST is great for CRUD, but not everything is that simplistic. Eg: Changes spanning multiple entities with transaction support. 3. Patchy PATCH support. Also, endless debates on whether something should be a PATCH or a PUT or a POST. The answer in some of those cases was that it couldn't be solved with clean REST. (Edit: added GraphQL)

LunaSea 11y ago
Do you have use cases that won't fit in a REST design ? I'm genuinely curious because as a web developer most of the problems I have encountered can be solved with API versioning, filters, paginations, scopes (limiting returned fields) and hierarchical URL structures (e.g: /users/:userId/comments/:commentId).
- jeswin 11y ago
  Let me use the example you have. 1. Clean RESTful URLs like the one you have doesn't make it easy to fetch { article, article.author.name, [user.comments.commenter] } in a _single call_. GraphQL let's you define the Shape you want. 2. Updates spanning multiple resources aren't a good fit for a Resource Oriented pattern like REST. a) How do you delete multiple comments (Ids 1, 34, 44) in one shot? http://stackoverflow.com/questions/7511195/rest-architecture-for-multiple-deletes http://stackoverflow.com/questions/7511195/rest-architecture... 3. How do I edit /users/200 and /users/201 in one single call? Imagine a Grid with a Save Button. Also, this could be a transaction as well. The above is doable with REST, but it is kind of a grey area and loses some of the obviousness seen in clean URLs such as in your example.
  - LunaSea 11y ago
    I agree that those cases would be tough to make work in a "clean" or at least standard RESTful API design but it's really improbable to encounter them. 1. This issue could be attributed to the database schema design imo. 2. In what case would you want to delete multiple comments at the same time ? I'm not trying to argue for the sake of arguing but I've genuinely never had to remove parts of an array that were not either a single element or the whole array. 3. Again I don't see a scenario where you would have to do this. If it's a consequence of another API call for example: You DELETEd a "group" so all of its member "users" should be deleted too. Than this kind of side effects or consistency CRUD should be handled inside the DELETE API call of the "group". I don't think that REST API design pretends to answer every single business logic use case but it does answer most of the common ones. In my opinion it's also dangerous to use a library that will abstract those difficult / unconventional use cases because they will feel easy to solve and hide the inherent complexity and cost that is present in the Database queries.
    - efdee 11y ago
      Case for point 2: Comment administration page. You get a list of comments with checkboxes, check the ones you want to select and then click "Delete selected". Case for point 3: Like he said, a grid (with inline editing) and a "save" button.
      - LunaSea 11y ago
        3. If you have a grid you also have pagination which eliminates the possibility of editing multiple rows in the same call.
      - colin_jack 11y ago
        I've put some thoughts below with references to cookbook recipes, I'm not saying they are in sweet point for a lovely resource oriented design but they are things you can handle. 1. Recipe 2.4 is one option. Alternative might be granular resources, if the characteristics of your use case means they can be done efficiently. For example we might include the URL to author details inside the article. That means another request, but if those author details are made immutable (as in change to author details means new URL), then they can be given a long cache period. Also HTTP/2 will mean more granular resources have different performance characteristics. 2. Recipe 11.10 could work so the URL would be the comments collection as a whole, I'd use PATCH (or POST if PATCH isn't an option) to then send the updates you need. So a PATCH to /<posturl>/comments with the result body including information that causes those comments to be deleted. 3. Same idea as 2, I'd use PATCH to the collection or a custom resource.
colin_jack 11y ago
1. I think though you'd really want to have some measurements regarding the performance impact of things like over fetching. Also remember that having a resource oriented design and working well with HTTP gives you out of the box advantages in terms of caching and validation, and in HTTP/2 you get extra efficiency advantages (e.g. lots of more granular resources can be retrieved over a single connection). 2. There are patterns for that though, often best approach is to represent that transaction as a resource. Restful Web Services Cookbook covers approaches for these sorts of bulk operations. 3. Not sure that's an argument against going resource oriented, if you don't find the debate interesting just ignore it.
Touche 11y ago
> REST is inadequate even for smaller companies, when it comes to the use cases Relay+GraphQL (or Falcor) tries to solve. Maybe it's slightly harder to implement those things in REST, but REST gives you HTTP caching and that's a killer feature. If you'd prefer to re-invent caching so you can use POST everywhere be my guest.
unoti 11y ago
> Also, endless debates on whether something should be a PATCH or a PUT or a POST. An often overlooked technique for handling such arguments is to quit bickering and get back to work solving the business problems.

picardo 11y ago

Anyone who builds APIs that talk to microservices has this problem, not just huge companies. As for the lock in, working in this paradigm would be impossible without a smart client library. Similarly, GraphQL has Relay. But Falcor's client side library is much more flexible than Relay, which is only a wrapper around React apps. If you have a non-React project, you have to use Falcor.