What it's actually doing is un-breaking HTTP caching and proxying semantics, so that we can meaningfully deploy those caches and proxies in a few years. That s

What it's actually doing is un-breaking HTTP caching and proxying semantics, so that we can meaningfully deploy those caches and proxies in a few years. That should help with scalability, and performance at scale. For example, if PUT is actually implemented properly, then you can implement write-back caching semantics with a general-purpose HTTP proxy. The way that Rails currently abuses PUT, a general-purpose proxy can only implement write-through caching (at best), or it needs to be customized for the specific application in use. Also, it's standardizing the language that developers are using to interact with each other, and reducing the amount of work needed to build interoperable software. As more and more websites turn into web services (even if those services are only consumed by e.g. client-side Javascript), this should result in cost savings and faster time-to-market as more businesses move in that direction. Finally, a lot of web apps are basically just CRUD (create/read/update/delete) apps. The more we standardize the on-the-wire protocols for these routine operations, the more we can push those protocols into application frameworks. This means that, as developers, we can work on things that are actually valuable, rather than coming up with new, site-specific ways of shuffling this data around the network.