We're not religious about REST. For example, see: https://www.pandastrike.com/posts/20151215-http-rest-great-better-developer-experience https://www.pandastrik

We're not religious about REST. For example, see: https://www.pandastrike.com/posts/20151215-http-rest-great-better-developer-experience https://www.pandastrike.com/posts/20151215-http-rest-great-b... and https://www.pandastrike.com/posts/20160210-rest-is-the-wrong-way-to-understand-http https://www.pandastrike.com/posts/20160210-rest-is-the-wrong... We've also tried to be specific in how you might approach addressing the limitations of HTTP in a way more consistent with the design of the protocol: https://www.pandastrike.com/posts/20151022-rest-data-api https://www.pandastrike.com/posts/20151022-rest-data-api and https://www.pandastrike.com/posts/20160509-http-is-the-new-lisp https://www.pandastrike.com/posts/20160509-http-is-the-new-l... In fact, our thesis in this article is not about REST at all, but the design goals of projects like Falcor, which may be unrealistic. And it's those unrealistic expectations of what's possible are why people are turning from HTTP.