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
- 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,
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:
- XML RPC
- Web Services
- Java RMI
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
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
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
- 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.