Comment by LunaSea | Hacker News Reader

Comment by LunaSea | Hacker News Reader

Parent Full thread

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.

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.

3. If you have a grid you also have pagination which eliminates the possibility of editing multiple rows in the same call.

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.

Is it unfair to think you're saying that a leaky abstraction is good?

I think it depends on the case but my point is that if you hide to the developer the cost of that abstraction than you will get some surprises in performance later on.

There are lots of reasons why an abstraction was written, ease of use being one of them but this also means that they don't always cover all bases (like performance). Which is alright if you (the developer) know about it.

Thanks to GraphQL or Falcor I can most likely do something like "return me an object containing table1.colA, table2.colB, table3.colC, ...etc." very easily but it also means that I just asked for at least two joins.

This can get really expensive if every developer on that project has the ability to do costly queries like this.

Falcor is intended to be used as a router to microservices, which could even be a REST api, not to database directly. A microservice would be between Falcor and the database. It isn't an ORM. It won't build a query. The services Falcor gets data from should have sensible limits that prevent unacceptable performance, whether you use them with Falcor or not.

Reply on news.ycombinator.com