December 10, 2007

Forgetting the hype over Web 2.0, the second generation of web development has spawned a huge back to basics movement which is reflected by the popularity of dynamic scripting languages and POJOs (Plain Old Java Objects). And among the most popular alternatives is Ruby, a declarative language ideal for database-focused applications, whose potential blossomed with the Rails web application framework.

This week, the second version of Ruby on Rails finally came out after about four years of work. One of the highlights of Ruby on Rails 2.0 probably isn't that surprising: promotion of the use REST over more complex SOAP-based web services. More about that in a moment.

In the meantime here's a brief laundry list of the some of the other enhancements:

• RoR sprinkles on improvements that separate rendering from UI templates to give you more flexibility when designing the look and feel of a Ruby application.
• It simplifies the mechanism for identifying specific records by providing “redirect” commands that let you turn classes of a model into “resource routes” (e.g., mapping an object to a target resource) on the fly.
• A number of enhancements cover security. For instance, in keeping with RoR’s goal to keep things simple and use what’s already there, it adds support for HTTP Basic Authentication (typically, name and password) encrypted using SSL. Also in the spirit of adding security, RoR supports using a special token so you can protect your app from receiving requests from an external, unknown source. And to deter cross-site scripting, RoR uses a “white list” approach where you specially identify who or where requests may come from.
• And there’s everything else. Examples include query caching to tweak Ruby’s notoriously slow performance; a simpler way to create Atom feeds; a more robust request profiler that lets you examine resource utilization over an entire script rather than just a piece of it; an easier way to declaratively state multiple exceptions to a specific action; and addition of support for JSON (JavaScript Object Notation, an alternative to XML) as a format for serializing data over the network. And the list goes on…

But the headlines remain emphasis on REST support. If you think about it, REST is a more logical match for RoR given that both were designed for data-oriented applications, and that both emphasize simplicity.

In an email, Rails creator David Heinemeier Hansson told us that “RESTful principles all steam from best practices of how to get the most out of HTTP and the infrastructure available for the web.” In other words, he says that because REST is in sync with the way the web works, which makes it a natural fit for Rails. (For more detail on Heinemeier Hansson’s response, click here.)

As background, REST (Representational State Transfer) is an architectural style of development rather than a standard per se. It involves working with a “representation” of a resource (e.g., data) rather than the resource rather than the resource itself, which is a lot like how the web itself operates. And when that representation is retrieved, the state of the client application changes in that it can move on to the next action. In some ways, that’s akin to a client/server application, excerpt that, instead of accessing (and working on) a database directly, you are working against a URI that provides the location of where you access that resource.

In so doing, REST (a.k.a., RESTful programming) is considered a much simpler alternative to requesting data services than SOAP, which was designed for much much more (headers of SOAP messages can accommodate attributes ranging from asserting trust, specifying token type, requesting reliable response, and so on, which is what all those Oasis WS-specs are all about).

---