From *Pixelcharmer: Field Notes: Cool URI’s:
I have a list of resources that argue for and suggest best practices in URI construction.
Great list. A few choice excerpts:
It the the duty of a Webmaster to allocate URIs which you will be able to stand by in 2 years, in 20 years, in 200 years. This needs thought, and organization, and commitment.
It is common for Internet users to glean information from URLs in order to help them hunt on the Internet for additional information. Of course, this practice often leads to unsuccessful searches, but modifying parts of a URL and submitting the changed URL to a server is a common search technique. The creator of a URL can help foster this kind of search with the names they choose.
The trick is to tell the outside world that your interface is one thing: /content/YYYY/MM/DD, but when you fetch the page, you’re accessing /content.cgi?date=YYYY-MM-DD. Web servers such as Apache and content management systems such as Userland’s Manila and the open source Zope support this abstraction.
The structure of a URL is a powerful and informative tool. It provides a way out of your navigational structure. If you’re trying to force users into a certain view of your site, this won’t help you — but why would you try to do such a silly thing? URLs allow users to get around inconveniences or flaws in your design, without requiring you to redesign your site.
Here are four simple rules for naming files that will let users navigate your site more comfortably:
1. Make sure your site has a meaningful layout. Organize files into directories and give the directories informative names. Remember that the layout must be consistent and rational: Having seen one part of it, a user should not be surprised by the rest.
2. Make sure each file’s name is useful and informative. Favor descriptive words, and definitely avoid serial numbers. Don’t have documents named “d1827.html”; how is a user supposed to learn anything from that?
3. Make sure each directory’s default “index” page exists, and allows users to easily navigate to every page in that directory. A user who gets to nearly-the-right page will often clip the file name from the URL and try again (although many report frustration with how often this yields nothing but error messages).
4. Finally, do not reorganize all the time! News sites, search engines, and users will have linked to pages on your site. If all I get when I follow a link to the “product page at the vendor’s Web site” is an error message or a redirect to your front page, I’m likely to go look at the next product I was thinking about in the hopes that I’ll get the correct page right away. Try to keep old URLs valid.
Some might argue that, in a perfect world, URLs would be used only by machines, hidden entirely from users. But in our imperfect world, users have come to depend on URLs to communicate key information as they navigate through the Web. Systems that don’t take this user behavior into account pull the rug out from under users who have come to rely on readable URLs. Recognizing that people really do read URLs ? and, in turn, making those URLs easy for people to read ? is really just an extension of the user-centered philosophy of design. It’s all about creating systems that work the way people work, rather than the way technology works.
Do not put too much meaning in a URI. as Berners-Lee writes, Designing mostly means leaving information out. If you put too much meaning, too much semantics in your URI, chances are your resource will evolve outside of the semantic frame, resulting in an unnecessary division of the resource or change of URI.
…
In order to make URIs easy to type, write down, spell, or remember, they should be short enough.
This checkpoint is not easy to quantify. However, we can take into account the fact that e-mail will be used to send URIs, and e-mail clients (sender or receiver) are supposed to wrap at 70-80 characters : even though they are not supposed to wrap long URIs, some do. As a result 80 characters is a reasonable total length for URIs (including URI scheme, e.g “http://”, and host name).
Please note, however, that this length limit is by no mean a technical limitation, but rather, a practical goal to pursue.
C. David Gammel, CAE 