Falcor is still in developer preview (https://github.com/Netflix/falcor). Otherwise the API (both on the server and the client side) look simpler than anything else I've tried so far.
You are also bound to use both their client-side AND server-side libraries which locks you completely in.
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)
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).
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...
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.
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 3: Like he said, a grid (with inline editing) and a "save" button.
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.
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.
/api/article/12/full to return the article with author and comments, and /api/article/12 for just the article text would work and aren't all that dirty. Could also be arguments to the REST call, but that makes it a little more ambiguous since you could have several different code paths for the same endpoint.
> 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....
The article you linked has a pretty graceful answer, I'm not sure why you dislike it. REST is generally a hierarchical datasource. Implement an endpoint above users in a hierarchy, or give it it's own tree. I.e. /api/comment/multi/delete, or /api/comments/delete (vs /api/comment). It's really not all that bad to do, and in a lot of cases you could use the same code to actually do the action.
> 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.
This is pretty much the same problem, you just have to handle more data. Again, /users/multi/update and POST your data.
The biggest place REST falls short of other HTTP-based API architectures is when you have a lot of different fields that need to be relatively randomly accessed. Sometimes you want the article with the authors name and date but no comments. Sometimes you just want the article name and author's name. Sometimes you just want the text. etc, etc. REST fails when you try to use it as SQL over HTTP, which looks to be what GraphQL is trying to do. And it's worth noting that it doesn't really "fail" per say, you just end up with a bloated mess of endpoints if you need to have 20 different variations on the data you need for an endpoint.
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.
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.
An often overlooked technique for handling such arguments is to quit bickering and get back to work solving the business problems.
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.