Ruby on Rails 1.2 deepens support to REST and Unicode

Posted by Luciano Ramalho on Jan 21, 2007

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Ruby on Rails ,

Ruby ,

REST

Tags

Announcements ,

Releases ,

Unicode

Ruby on Rails 1.2 is finally out, as a release numbered 1.2.1 that updates many key components of the framework. 'Mature' is perhaps the best adjective to describe the latest version. The most important change is arguably "REST, and general HTTP appreciation", to quote the official announcement. In other words, the framework now leverages more advanced features of HTTP. For instance, CRUD operations can now be directly mapped to the native HTTP verbs POST, GET, PUT and DELETE. REST-style mapping simplifies URLs by reducing the need for naming actions in the path, and paves the way to refactoring bloated controllers into simpler, more focused ones. Another major enhancement is better support for UTF-8 encoded strings.

David Heinemeier Hansson appears to have pored over Roy Fielding's PhD dissertation, which defines the acronym REST (Representational State Transfer) as the architectural style of the Web. Fielding is one of the founders of the Apache project, the lead author of the HTTP/1.1 standard, and his work put HTTP and the whole WWW on solid theoretical grounds.

Besides using additional HTTP verbs, Rails controllers can now render multiple formats from the same base URL invoked with different file extensions (i.e. /blog and /blog.rss both invoke the /blog controller, but one renders HTML and the other RSS). David's keynote at the 2006 RailsConf (video, slides) previews these changes, and shows how they support his opinionated (and agile) approach to SOAs without the baggage of SOAP. By digging into HTTP, the Rails team once again shows an easy to follow path towards building web apps the right way.

Ruby is set to finally support Unicode by the end of 2007. Meanwhile, the Rails team has created a Chars class to proxy the native String class and provide encoding-safe operations, such as a slice method that does not mangle multibyte characters. ActiveSupport::Multibyte adds a String::char accessor which returns a Char instance representing the String, so if you do title.chars[0,7] you get a Char instance containing the first seven Unicode characters of the title string (and not the first seven bytes).

It's reassuring the see the Rails team committed not to bells and whistles, but to perfecting the architecture and the infrastructure of the framework. Another sign of maturity: 57 distinct developers sign the changelog for 1.2, more than twice the number in the previous minor releases (27 in 1.1, 18 in 1.0). There are 108 items in the 1.2 changelog, versus 62 in 1.1, which was released in March, 2006. Ruby on Rails definitely seems poised for another year of explosive growth.

1. Back to top

   action in the url?

   by Dan Diephouse

   Anyone else notice how they are sometimes putting ";edit" in the URL to map it to the edit action? I'm not a Rails expert, but that seems a bit non-RESTful to me. Anyone want to comment what the difference between the edit and the update actions are for a non Rails guy?
   
   Dan Diephouse, Envoi Solutions

   Reply

2. Back to top

   Re: action in the url?

   by Obie Fernandez

   Adding ;edit to an individual resource URL tells Rails that you want the edit form in order to do an update (via a PUT)

   Reply

3. Back to top

   Re: action in the url?

   by James Strachan

   Dan, the ";edit" on the URL is purely as a work around for browsers and firewalls which don't support PUT/DELETE - so its a way of differentiating operations when only GET and POST are supported. i.e. its a way to support loREST as well as hiREST.
   
   Basically you can use Rails in a perfectly RESTful way - the REST support in Rails is awesome (as is the rest of it :).
   
   James
   LogicBlaze

   Reply

4. Back to top

   Re: action in the url?

   by David Easley

   > the ";edit" on the URL is purely as a work around for
   > browsers and firewalls which don't support PUT/DELETE
   
   Wrong. There's a separate hidden field in the POSTed form for that. ";edit" is essentially a hint used with a GET URL. It says to the server "Give me the specified resource in an appropriate format for editing". So "GET /users/1" might return the user details formatted as a report while "GET /users/1;edit" returns the user details in a form. If and when the form is the browser sends the form params to "PUT /users/1". Except, because of the problem Dan mentioned, PUT can't be relied to work, so instead POST is used and a hidden form field is used to signal to the webapp framework that it should treat it as a PUT.
   
   David

   Reply

5. Back to top

   Re: action in the url?

   by Stefan Tilkov

   There's nothing unRESTful about that ;edit URI. Doing a GET on it is "safe", the only difference is the one pointed out by David.
   
   I asked the combined REST commuity about the Rails REST concepts in the Yahoo! mailing list; IIRC, there was no significant criticism. The only exception is the hidden form field workaround, which is used not only by Rails, but also by Google's GData (for example) -- some consider this wrong and believe applications should not try to work around the PUT/DELETE limitations in many firewalls. The reasoning is that firewall admins a) need to learn the errors of their ways b) have good reasons for blocking PUT and DELETE.
   
   I don't subscribe to this point of view.

   Reply

• Older >