Draft - Make readable URIs

This is a draft "webmaster tip", under work and review by the Quality Assurance Team, and shouldn't be considered as an official tip from W3C while it remains a draft.

This draft is based upon the draft by Victor Engmark and tries to take into account the feedback received.

By design, URIs are supposed to be mere identifiers, meant to be processed by Web agents and servers. URIs are also supposed to be rather opaque, which means that they do not necessarily "mean" anything, and that there is no guarantee they do even when they seem to.

Machine processing and human comprehension and reproduction of URIs are, however, not anthetical. Similarly, the "opacity by design" of URIs does not mean they must be overly complicated. On the contrary: well designed, user-friendly URIs can result in easier management and an increased readership.

Why readable URIs?

Human-processable URIs spread better through word-of-mouth and plain-text communication, which is a useful lever: when a URI has to be advertised through a medium that doesn't easily support following hypertext links (e.g. a URI written down on paper), it's much easier for the user to have to type a simple URI rather than a unreadable one.

Here are a few criteria worth considering when choosing a URI:

Simple recipes for simple URIs

Using technology-independent URIs

One of the most simple techniques for creating simple URIs is to leave out any hint of technology-specifics:

This technique has a valuable side benefit: By hiding the technology you are using, you also make your URIs future-proof. Fewer headaches and no broken link when you change the technology used to serve your content.

Other techniques and recipes

There are plenty other techniques available to serve your content with reasonably simple URIs. Below is a short list of some which could be useful and worth using:

  1. Using language negotiation. Language negotiation (one aspect of content negotiation, introduced above) allows you to serve several equivalent resources in different languages. In most servers this is achieved by using the same resource name prefix followed by a language code suffix (e.g http://www.example.com/foo.en, http://www.example.com/foo.no)
  2. Using directory indexes: Most servers can be configured to serve a certain file as a directory index, e.g http://www.example.com/products/ will be similar to http://www.example.com/products/index.html

Further Reading

Valid XHTML 1.0!
Created Date: 2003-08-26 by Victor Engmark
Last modified $Date: 2004/08/23 03:12:53 $ by $Author: ot $
