A Community for REST

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.

  1. James
    July 28, 2006

    > one part a unified community (Rails is the way to develop Web applications if you use Ruby)

    Actually, Rails is not always the best choice, and there are other Ruby options.

    They may not have the same number of supporters or public attention, but that has never been an indication of quality or value.

    It’s simply wrong to suggest that there is only one viable choice, or that every Ruby hacker prefers Rails for all Web development.

    This is not to detract for Rails, which is clearly a remarkable tool. It’s just not the only one, or the best one for all cases.

    Reply
  2. Charlie
    July 28, 2006

    Hi James – good points, I don’t mean to take away from other efforts such as Nitro (or home grown solutions) It’s of course always good to have competition.

    However, I do think Rails dominates the Ruby community more than framework in other languages (python, php, perl) dominate theirs.

    Reply
  3. July 28, 2006

    I think the language is more relevent than you might think. While Python makes metaclass hacking possible, Ruby makes it trivially easy, and thus the practice of extending the language at runtime and creating micro-languages (DSLs) in Ruby has become deeply embedded in the Ruby developer culture in a way that simply hasn’t happened for Python. Rails exploits these techniques to the max. While Rails might have been possible in Python, I doubt it would have been as easy, and it certainly would not have found as much immediate acceptance from the Python community.

    Reply
  4. Charlie Savage –
    July 28, 2006

    Hi Avdi,

    I think a lot of people would agree with you – I’ve had long discussion about it with [Peter](http://pezra.barelyenough.org/blog/) and [Donnie](http://www.donaldmarino.com/). You hit on the two key points. First, Ruby’s DSL support and, second, the differences in culture between the Python and Ruby communities.

    You may be right, but I still think that the success of Rails is due more to marketing/political/luck factors than to technical factors.

    Reply

Leave a Reply

Your email address will not be published.

Top