One of the great ironies of the Web is that a huge number of technical people refuse to believe what is right in front of their eyes. The Web is the world’s most diverse and powerful information system – one that has massively scaled from a single user at its inception to hundreds of millions today and billions tomorrow. REST is deceptively simple – its based on three fundamental design decisions:
- Agreement on a global addressing scheme, URIs, to identify resources.
- Agreement on a limited, generic application interface to manipulate resources.
HTTP provides this generic interface via its “verbs,” which include GET, POST, PUT, DELETE, etc. - Agreement on common formats, particularly HTML, to represent resources. Over time additional formats have been added, including JPEG, GIF, PNG, SVG, etc.
The Siren Call
Yet these lessons have been ignored time and time again. People just can’t get past the siren call of building distributed systems using distributed objects. Let’s count the failures:
- DCOM
- CORBA
- XML RPC
- SOAP
- Web Services
- Java RMI
- JNI
And hundreds of home grown solutions that will never make it outside the Enterprise walls. Like I wrote last spring, every developer I’ve ever met who has written a distributed computing system always write their own RPC mechanism. I know, I’ve done it.
REST proponents have been struggling to get their message across for years. A the height of the Web Services myopia, REST was portrayed as an overly simplistic solution that most certainly was not adequate for building Enterprise applications.
Five years later the tide has turned – the evangelization of REST believers is starting to pay off. And they are about to be joined by a new champion – the Rails community.
A New Champion
It looks to me that the Rails community is about to become the first main-stream web development community to fully embrace REST.
Over the last year, the Rails community has been learning Web architecture best practices at light speed. Watching this has been quite refreshing – there is surprisingly little “not invented here syndrome.” Some of the fundamental changes have included:
- RPC style controllers to REST style controllers
- Closely related, the move to CRUD interfaces
- Changing deployment from Apache/cgi to Lighttpd/fastcgi to http load balancing
with Apache/Mongrel - Some support for content negotiation to allow the reuse of controllers for creating multiple types of representations
As discussed above, its no surprise that Rails started down the wrong path on these architectural issues. What is a surprise is how quickly the Rails community has discovered its mistakes and starting fixing them. The ability to rapidly adopt is partially due to the community’s youth, which frees it from the shackles of a backwards compatibility required by an installed base. But its also a characteristic of the community.
At the same time, Rails has been quickly grabbing mind share and market share. Adoption hasn’t been driven by technical superiority – if David Heinemeier Hansson used Python I think we’d be talking about Python on Rails today. Instead, adoption has been driven by one part marketing, one part a unified community (Rails is the way to develop Web applications if you use Ruby) and one part luck. Web Services have almost run their course, J2EE is creaking under its own weight and .NET has not taken over the world. Now that the Web is hip again, there is a vacuum that is ripe to be filled by a new platform. PHP has clearly filled most of this void, but Rails has grabbed itself a niche that is growing quickly.
The combination of the Rails marketing juggernaut, its growing market share and the community’s move toward REST all point to a new champion for the REST architectural style. It will be interesting to see if this final nudge pushes the REST style architecture over the tipping point so its finally appreciated by the majority of the technical community as opposed to a few enlightened souls.