

Why the future is Not RESTful - systems
http://z.caudate.me/why-the-future-is-not-restful/?utm_source=dlvr.it&utm_medium=facebook

======
danpalmer
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/](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.

~~~
zcaudate
Thanks for the link to Rocket. It will definitely be interesting to see how
everything plays out =)

------
memracom
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.

