At the beginning of his presentation, Jafar Husain explained how a team at Netflix started out with a mostly RESTful API, but then it degraded to RPC. That suggests to me that REST really wasn't the best fit for their requirements. It's easy for us to say from the sidelines that they should have just tried harder to stay pure and follow the REST way. But requirements change, and the REST architectural style wasn't designed for today's world, where users don't want to think about the distinction between their devices and the network. I think it's quite likely that Relay and Falcor, having been designed by teams working on large-scale consumer applications, really do make some progress toward solving some problems these teams face better than REST does.

More generally, I'm skeptical of any hard-line position which insists that you just have to stay pure and follow the true way. I already rejected one religion; I don't want to get sucked into another.

We're not religious about REST. For example, see:

https://www.pandastrike.com/posts/20151215-http-rest-great-b...

and

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

and

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.

OK, I was wrong to accuse you of being religious about REST. Thanks for the links.

:)