Summary
In his RailConf keynote, Rails creator David Heinemeier Hansson explained his reasoning for preferring numeric entity IDs in URLs as opposed strings. What's your opinion?

In his RailsConf keynote address, Ruby on Rails creator David Heinemeier Hansson discussed the issue of whether to use numbers corresponding to database keys in URLs (as in /people/1) versus using string keys that may have some semantic meaning to users of the web application (as in /people/bob).

We're expecting you'll want to use auto-incrementing IDs for things. And I expect that will be as controversial a point as auto-incrementing IDs and saying that that's the way you should do it was with databases. Because most people have this notion that you should have friendlier URLs. It is funny how I have not heard too many people spot that obvious comparison.

People say we want to have the title of the blog posting in the URL. You want real keys? You want those keys that burned on the stake in the database design back in your URLs? Why? The exact same arguments apply. I fell under the exact same thing. In basecamp, we used to have something like /client/37signals. Well what would happen when people changed their firm name? They would now call themselves 38signals. It broke. You have broken URLs. You have exactly the same problems that you had in the database world. Not very nice.

So what I've come to realize is that it's just not worth it. It's just not worth describing these comcrete logical things in the URLs because you get the same mess when we tried that in the database world.

The counter argument is that URIs are part of the user interface of a web application, at least if the application is designed for human consumption. (Hansson's comments at RailsConf were in the context of describing ideas about ActiveResource, a work-in-progress API intended to make it easy to write web service clients, but the conventions he described are intended for human users as well.) Jakob Nielsen gives his take on this issue in URL as UI, suggesting that a usable site requires:

• a domain name that is easy to remember and easy to spell
• short URLs
• easy-to-type URLs
• URLs that visualize the site structure
• URLs that are "hackable" to allow users to move to higher levels of the information architecture by hacking off the end of the URL
• persistent URLs that don't change

Similarly, the W3C document, The Use of Metadata in URIs, contains a section of the usability benefit of guessable URLs.

Bob is walking down a street, and he sees an advertisement on the side of a bus:

"For the best Chicago Weather information on the Web, visit http://example.org/weather/Chicago."

Bob goes home and types the URI into his browser, which does indeed display for him a Chicago weather forecast. Bob then realizes that he'll be visiting Boston, and he guesses that a Boston weather page might be available at a similar URI: http://example.org/weather/Boston. He types that into his browser and reads the response that comes back.

Bob is using the original URI for more than its intended purpose, which is to identify the Chicago weather page. Instead, he's inferring from it information about the structure of a Web site that, he guesses, might use a uniform naming convention for the weather in lots of cities. So, when Bob tries the Boston URI, he has to be prepared for the possibility that his guess will prove wrong: Web architecture does not guarantee that the retrieved page, if there is one, has the weather for Boston, or indeed that it contains any weather report at all. Even if it does, there is no assurance that it is current weather, that it is intended for reliable use by consumers, etc. Bob has seen an advertisement listing just the Chicago URI, and that is the only one that the URI authority has warranted will be a useful weather report.

Still, the ability to explore the Web informally and experimentally is very valuable, and Web users act on such guesses about URIs all the time. Many authorities facilitate such flexible use of the Web by assigning URIs in an orderly and predictable manner. Nonetheless, in the example above, Bob is responsible for determining whether the information returned is indeed what he needs.

Notably, Jakob Nielsen mentions "persistent URLs that don't change," in his list of requirements for usable websites, the very example that David Heinemeier Hansson mentioned as a problem when using string keys in URLs. The importance of persistent URLs, and suggestions for how to achieve them in URL design, is given in the W3C document, Cool URIs Don't Change. It is indeed important to think hard about URL design before publishing a URL, because changing it later is difficult.

But the truth is that Real URIs Do Change, and the web is flexible enough to accomodate that change. It takes a little more work on the web site developer's part, because you have to redirect requests from old versions of the URI to the new one. But that does work. If /client/37signals changes its name to 38signals, then it could have its client page moved to /client/38signals, and /client/37signals could perform a 301 redirect to /client/38signals. In such a situation, neither the web application nor the /client/37signals URL is broken—but it does make life more complicated for the provider of the service. Ruby on Rails is very strong on making things simple for the developer, and that's a great thing, but the tradeoff in this case may be a small subtraction in the usability of the site. It may be worth it, because gaining access to the application sooner in the first place, which Rails may facilitate, is a big usability plus. But there is a tradeoff being made.

In my interview with Ken Arnold, Perfection and Simplicity, he suggested thinking from the user in rather than from the implementation out:

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 is your opinion on this issue? To what extent is a string key in a URL actually more user-friendly than a numeric one? To what extent does that usability boost matter? In short, when do you think it is worth the extra effort on the part of developers, and when not?

Talk Back!

Have an opinion? Readers have already posted 10 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.