URI Thoughts
Ever since I read Matthew Thomas’ outline of an ultimate weblogging system I’ve been thinking about URIs.
It is useful to be able to visit bbc.co.uk/football or bbc.co.uk/cricket and be redirected to the appropriate section in the BBC site (currently http://news.bbc.co.uk/sport1/hi/football/default.stm in the case of football).
Even more useful is the new URI scheme in place at ebay. my.ebay.co.uk, search.ebay.co.uk/ipod and search-completed.ebay.co.uk/microwave all do what you would expect them to (take you to “my ebay”, search current auctions for iPods and search completed auctions for microwaves) both saving time and increasing clarity and usability.
The question then is, what is the best URI scheme?
Of course, this depends on the site. One thing that I think is undisputed across sites is that URLs should not include extensions that give away technology choices. There is no advantage to the URL:
http://example.com/products/default.asp
over:
http://example.com/products/
and the former makes migrating away from ASP (even to ASP.NET) more problematic than it needs to be.
Another no-brainer is that URIs should be short. Short URIs are easier to remember and URIs over 78 characters long will wrap in some emails.
Jakob Nielsen (in
URL as UI) found that mixed case and non-alphanumerics confused users. So let’s ditch those too. That means that a query string (?x=1&y=8394) makes a URI harder to read and less usable. Links with query strings (or sometimes only complex query strings) are also ignored by some search engines. There is a good discussion of this in Toward’s Next Generation URLs.
Without producing a static version of a site every time you make a change (which may actually be a workable solution in some cases) you can use URI rewriting to let your users have usable URIs but give the webserver the query string it needs to serve up the right content. This can be done with ISAPI Rewrite on IIS (Lite version is free, if not Free) and mod_rewrite on Apache.
With URI rewriting it does not matter what URI the underlying technology needs you just need to decide on the appropriate scheme and write clever enough regular expressions to implement it.
It would be possible to run a site where every URI is of the form:
http://example.com/7
http://example.com/23
http://example.com/274383
but that fails the user in that it provides no information about the page and prevents user from using urls to navigate the site. It seems that some “directory structure” is required (although it may not reflect the actual directory structure of the site) and then a name for the page of content should be appended to that.
Cool URIs don’t change suggests dates as an effective
structure and suggests that categories are too changeable over time to work.
An Example
The posts on this site currently have URIs in this format:
http://bluebones.net/news/default.asp?action=view_story&story_id=97
There we have underscores, a question mark and an ampersand plus the URI tells you very little about what you might expect if you clicked on it. Ripe for improvement. Here are the possible schemes I have considered:
A
bluebones.net/posts/96
Very short but not too informative.
B
bluebones.net/posts/2001/06/14/96
Not so short and still fairly oblique.
C
bluebones.net/posts/2001/06/14/internetboggle
bluebones.net/posts/2005/03/13/awstatsoniis5witholdlogfiles
I like this but the longer titles make the URIs overlong.
D
bluebones.net/posts/internetboggle
bluebones.net/posts/wherewizardsstayuplatetheorigins
oftheinternetbykatiehafnerandmatthewlyon
Even with the date structure removed some posts titles are too long to be included in the URI. And what to do about posts with the same title?
E
bluebones.net/posts/internetboggle
bluebones.net/posts/wherewizardsstayupla
Truncated to 20 characters is OK but you can imagine some horrorshow URI caused by truncating at exactly the wrong point and the content is not so clear. The issue of posts with the same title is even more relevant here.
F
bluebones.net/posts/internetboggle
bluebones.net/posts/wherewizardsstayuplate
This is the scheme I am planning on implementing. The need to cope with duplicates in any scheme that uses strings and not integer ids means that some work will have to be done (by the server) upon posting that is not being done now. Given that I am going to have to write some code anyway, why not just add an extra field when posting (which could be autopopulated with a default of the title with all spaces and punctuation removed) that is called “link” or similar and appears after /posts/ as above. Of course duplicates will have to be checked for and either reported to the user or otherwise dealt with here, too.
What do you think? Help me out before I make irreversible decisons by commenting below.
