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.

Page caching is the simplest form of caching that Ruby on Rails offers. When invoked, page caching saves output to Rails’ public directory where it is subsequently served along with the other static pages. Of course this is advantageous for high traffic sites or pages that are slow to render. In most cases, page caching works without any config file editing. I, however, encountered a minor problem that prompted me to investigate this simple mechanism a bit further.

Rails Configuration

Just add one line to a controller to enable page caching:

class DemoController < ApplicationController
  caches_page :show

The caches_page() method instructs Rails to cache the output of the indicated actions. In the above example, Rails will save the output generated by the show action to the corresponding public directory. For example if a browser visits http://server/demo/show/123, cached output will reside in the file public/demo/show/123.html. For future requests, the web server will use this static file rather than running any Rails code.

If you would like Rails to expire the page, the easiest option is to call the method expire_page(). Arguments follow the same syntax as url_for. Under the hood, page expiry simply deletes the cached file. To expire the file created in the previous paragraph: expire_page :controller => "demo", :action =>, :id => 123

By default, caching directives are ignored unless RAILS_ENV=”production”. You can explicitly control caching for each environment by specifying config.action_controller.perform_caching = true in the appropriate environment file (e.g. “config/environments/development.rb”).

Web Server Configuration

Notice that Rails appends an “html” extension to cached pages. This extension allows the web server to treat the file like any other HTML file for determination of MIME type, permissions, etc. However, the extension also means that the web server must be configured to internally append “.html” to serve the cached page. Rails’ skeleton directory includes an Apache configuration file (public/.htaccess), and a Lighttpd configuration (config/lighttpd.conf), which do just that:

RewriteEngine On
RewriteRule ^([^.]+)$ $1.html [QSA]

server.modules = ( "mod_rewrite", ... )
url.rewrite += ( "^([^.]+)$" => "$1.html" )

Notice the regular expression common to both configurations: ^([^.]+)$. In English this translates to “if a request does not contain a period: ^([^.]+)$, then internally append ‘.html’ to that request: $1.html“.

My Original Problem: Firefox Ignoring Updates

I encountered what may be an isolated issue wherein Firefox 2 consistently failed to update pages whose contents expired via expire_page(). “about:cache” revealed that FireFox was setting a brief expiration time on static pages, and was using the old cached copy rather than requesting the current server copy. The workaround was easy enough – tell the web server to immediately expire cached pages. Continuing the above example, the Apache config should reside in public/demo/.htaccess, and the Lighttpd config should be added to lighttpd.conf:

ExpiresActive On
ExpiresDefault Now

server.modules = ( "mod_expire", ... )
$HTTP["url"] =~ "^/demo" {
  expire.url = ( "" => "access 0 seconds" )
}

These directives cause the web server to append Expires (HTTP 1.0) or Cache-Control (HTTP 1.1) headers that instruct the client to request the page anew for each display. This is less bandwidth-efficient, but that was not an issue for the intranet site I was working on.