Why the future is Not RESTful

I think caching is still a big deal. It massively increases the responsiveness of web applications, and probably also improves access for mobile clients who are on poor data connections. Not to mention the 2/3rds of the world who don't have a fast or stable internet connection.

I think the future is actually more REST. Most REST on the web at the moment only really reaches the first 2 levels of the Richardson Maturity Model, but it's level 3 (the final one) that gives you many of the benefits over alternatives.

The big issue in the future is not enabling the developer to write more 'live' services with things like Meteor, it's enabling computers to figure most of it out themselves. A REST client should be able to consume a REST web service with very little involvement, and few design-time decisions by the developer. It should be able to discover resources, and adapt to API changes by itself. This makes making clients for services much easier, and is far more 'client focused' than Meteor, which at the moment is a bit of a black box for clients that aren't Meteor web pages.

I think additional ideas like Rocket (http://rocket.github.io/) could be integrated into the conventions for a nicer interface to the data, but generally I think REST is a good way to go.

Caching doesn't only happen in proxies. Clients can do it too and your app is a client and should cache what it can.

But the real problem with REST is round trip times and that is an artifact of REST being build on top of an RPC protocol. The future is EVENTful and I am not talking about websockets or any specific implementation of events. Fire and forget messaging is the way of the future.