Summary
In his weblog, Peter Williams points out that Rails' default URIs are procedural, rather than RESTful, because they include an action name. I believe Rails' default URL scheme also puts the developer before the user.

In his weblog, Peter Williams points out that Rails' default URLs are procedural, rather than RESTful, because they include an action name, and suggests some alternative approaches. (REST is an architecture style for distributed systems, and a popular way to think about the web.) For basic example of a Rails URL, Peter gives:

http://example.com/product/show/1

By default Rails will map this URL to the show method on the product controller, passing in 1 as an ID. Peter suggests this is unRESTful because REST says that the web is a web of information resources on which you can take actions like GET, POST, PUT, and DELETE.

A few months ago Frank Sommers and I spent four fun days playing with Rails, and one of the problems I saw we would have trying to apply it to our requirements was in the area of its URLs. David Heinnemeier Hansson showed me Rails a couple of years ago, and I can still remember him gleefully saying, "I like pretty URLs." He worked hard in Rails to prevent developers from creating apps with URLs like:

http://example.com/product?action=show&id=1

To make development faster, he also wanted to make sure that by default, developers wouldn't have to configure a mapping from URL to controller and action, hence pretty URLs. The default Rails URLs are indeed prettier than the URLs that come out of a lot of web frameworks, but I believe they could be prettier, because they favor the developer over the user.

Tim Berners Lee suggests that URIs should be opaque:

The only thing you can use an identifier for is to refer to an object. When you are not dereferencing you should not look at the contents of the URI string to gain other information [or do so] as little as possible.

While I believe in this philosophy of opaque URLs when software deals with URLs, for better or for worse, it is not the case with users. The URL is a part of the user interface, and therefore it is an opportunity to communicate with the user about the information architecture of your site. When designed with the user in mind, URLs can help users figure out where they are in the structure of your site. In addition, I agree with Jakob Nielsen that users should be able to hack off part of the URL to move up a level in your information architecture.

In Rails you can, of course, name your controllers with the user's model of the information architecture in mind. However, after that the name of the action slips into the URL. This happens because in Rails the controllers don't have handler methods for the various HTTP methods (such as processGet for a GET request, etc.). Instead you can define any number of handler methods with verb names indicating what they do, like show or add_to_cart. This allows the developer to put related methods into one controller, which allows them to easily factor out common code into private utility methods. These handler method names then show up by default in the URIs, and therefore, the user interface, so that the developer doesn't need to configure them explicitly (convention over configuration). It's one way Rails helps you create web apps quickly (which, I might add, is something users also like).

Nevertheless, this approach in Rails reminded me a bit of this part of my interview with Ken Arnold:

Ken Arnold: It takes a lot more work to understand the other person than it takes to understand you. You might say, "I have these two things together so I will let the user—the person using the API—manipulate them." But that user didn't say, "Hey, I want to manipulate these two data structures!" Often the user is saying, "I want to get this result." If users could get a result without manipulating the data structures, they'd be happy as clams. If you can make it more natural for them to get that result, the fact that you have to go through 10 times as much work to access those data structures is good; it means you are providing value. Many people are much more likely to think about what they have in hand and what they can do. They think from the implementation out, instead of thinking from the user in.

What was interesting to me when I read Peter Williams' blog post about RESTfulness in URLs, was that I realized that my notion of user-friendly URLs is very much in sync with REST. URLs that provide users with a mental model of your site as a hierarchy of information resources means that each URL maps to a resource. What can you do with that resource? Retrieve a representation of it with GET, and make updates to it with POST.

Talk Back!

Have an opinion? Readers have already posted 9 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bill Venners adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala.