Rails makes it easy to relate URL’s to their respective controller methods. If you want another action, just add the method to the controller and append the name to the controller URL. However, this controller-centric approach is a mixed blessing, because it lends itself to redundancy and extraneous methods. The recent Rails 1.2 release introduces RESTful facilities and a resource-centric URL structure that makes it easier to remove the junk and keep the CRUD.

Keep the CRUD?!

CRUD refers to the four basic actions that we apply to web data: Create, Read, Update and Delete. In his 2006 RailsConf keynote, David Heinemeier Hansson describes the benefits of viewing your models through the lens of CRUD, arguing that in many cases, operations beyond the basic four often just incur controller bloat. As an example, he ponders options for defining a relationship between Users and Groups. The traditional approach would be to implement the group join as UsersController#join_group or perhaps GroupsController#add_user. A third solution would be to create a new class, Memberships, that relates Users to Groups. This distills membership management to the CRUD functions – MembershipsController#create. While an extra model might seem to increase complexity rather than reduce it, consider the benefits of a consistent set of functions in every controller. Also recognize the ease with which we can extend Membership — Membership#joined_at, Membership#authorized_by, etc.

Get some REST

Roy Fielding introduced REST, or Representative State Transfer, in chapter 5 of his 2000 dissertation. REST is basically an idealized web architecture in which resources (data) are manipulated through a generic interface (e.g. CRUD!) — a client can Create an User just as easily as it can Delete a Membership. In a REST architecture, messages that retrieve or alter the state of a resource are called representations. This abstraction offers data formats that are appropriate for each interaction — a PDA might Update inventory represented using standard HTML forms, while a PC browser might Read an XML representation of that same inventory.

Enter Rails 1.2

David Heinemeier Hansson describes how nicely the CRUD functions align with SQL commands and HTTP methods:

Rails 1.2 takes advantage of these similarities. Compare the HTTP used to access previous “/controller/action/id” routes with the newer “/resource/id” routes:

Notice how traditional routes include the action in the URL, and use only GET and POST. The RESTful URL’s refer to resources, and the controller infers the action from the HTTP method and headers. In what Hansson calls an HTTP “renaissance”, Rails 1.2 now embraces PUT and DELETE, and acknowledges a client’s “Accept” and “Content-Type” headers. Unfortunately web browsers don’t support PUT or DELETE, but Rails emulates them through a POST with the hidden variable “_method”.

Rails’ new RESTful scaffold generator (script/generate scaffold_resource) is a good place to get started with the new facilities. When run without any arguments, the new generator gives a basic overview of it’s usage.

Just the beginning…

Pretty URL’s and uniform controller methods barely scratch the surface of the benefits imparted by REST. Consider the potential use of a generic HTTP interface as a simple web API. The prospect of being unencumbered by the complexity of SOAP opens the doors for use with AJAX and in simple scripts. Fielding’s dissertation goes on to describe the caching and scaling benefits of a pure REST architecture.