Mihai Mobile

The URLs that are used to access an web application are important, they are part of the interface to the application. Here I put together some random principles which should help towards a quality URL design.

1. Keep URLs short. Short is easy to remember, to edit in the address bar, to write down, etc. The most often used URLs should be the shortest.
2. Don’t use file extensions (such as .html, .gif, .php, etc.). The extension is an implementation detail that doesn’t need to be presented to the user.
3. Normalize URLs. Every entity should have one canonic URL. Have other URLs that point to the same entity use HTTP redirects to the canonic URL.
4. Normalize the domain name to the form without the leading “www.”, because it becomes shorter. The leading www. doesn’t add information for the user.
5. A path which accepts to be continued with more segments should behave like a directory, i.e. should be normalized to have an ending slash.
   If http://x.org/user/john is a valid URL, then http://x.org/user should redirect to http://x.org/user/ (note the appended slash).
6. If a path is valid, then any prefix path should be valid too.
   If http://x.org/admin/user/john is valid, then these should be valid too: http://x.org/admin/ and http://x.org/admin/user/ .
7. Have the prefix URL allow exploration (browsing) to the possible suffixes that may follow it.
   In the case of http://x.org/country/brazil : http://x.org/country/ may provide a list of possible contry names, with links.
   In the case of http://x.org/user/john : http://x.org/user/ may provide an input field for entering an user name if the number of users is too large to enumerate them all in a list.
8. Avoid ‘query’ parameters in URL. Instead of http://x.org/?p=101 use http://x.org/p/101 . An exception are the form-action URLs which get the parameters appended due to the form submission.
9. Avoid session-IDs or other long binary (opaque) identifiers in URLs. If you really absolutely need an opaque identifier in the URL, then make the information as short as possible (number of bytes) and encode it in the most compact way (e.g. base64).
10. Try to have homogenous levels, where all the continuations (suffix segments) of an URL are of the same kind.
    Example: If http://x.org/user/ is continued with ‘john’, ‘andy’, ‘mary’: it’s good, all the continuations are user names (nouns).
    But if http://x.org/user/ is continued with ‘john’, ‘edit’, ‘remove’, ’102′, ‘new’: bad, because ‘edit’ and ‘remove’ are actions (verbs), ‘john’ is a noun, ’102′ (noun too) is an id and not a name, ‘new’ is a noun but designates an action (add), etc. This level is not homogenous (it’s mixed-up).

It’s great if a web application has such a simple (and nicely structurated) URL space that the user, after some use of the application, aquires a mental map of the URL space. From that moment on he won’t have the sentiment of being lost in a huge URL spaghetti anymore. He achieves orientation: by simply looking at the URL he knows where he is and where he can go. He can even extrapolate from the observed URL structure and explore new URLs.