chrispoole.com

There seems to be a lot of different opinions on various ideas behind what the structure of a URI should be.

These represent my opinions on the matter, and various ideas that have popped into my head recently. Some of the ideas should be taken with a rather large pinch of salt. Ignoring the current phishing problems of IRI’s, one may read IRI for all URI at many places. (places, phishing.. hah!)

Trailing Slashes

I think it’s best to leave out any trailing slash as:

1. The URI looks nicer with no trailing slash. simple
2. I don’t really believe that the visitor needs to know (or wants, for that matter) whether the URI they have typed points to a directory (that points to some default file, say index.htm) or a file directly

The latter point also implies that the URI structure is linked with the file structure of the site on the server. This does not have to be the case at all. If there is a direct link, then so be it. But if there is no direct link, it means that one can change the file structure without changing the URI. And we all know Cool URIs don’t change. As Anne writes, this could allow the author of an article to be referenced within the file structure, but not be within the URI structure.

Concerning File Extensions

Several people have brought up issues about file extensions. I believe Anne generally thinks that one should not use extensions for markup documents, images or otherwise. My thoughts on the matter are that he is essentially correct; a URI such as /contact should be used instead of /contact.htm. Not only is this far more memorable and thus accessible, but it also keeps the page independant of the technology used to construct it. This is good, as if one changes the language that they use to write the page, then this will change the extension, which means that the URI would also change. And as stated above, cool URIs don’t change. I believe this is something a web developer should always try and ensure (where possible).

For those who wish to serve the same content in different ways, a URI with no file extension could be used with some backend scripting to decide what document format is best to send the user. One may wish to add in the ability for the visitor to add in the extension to force what document type is served.

This could also be extended to other document types of course, for example, images. So one could point to a certain image file with no extension given, and receive either a gif file or a png file. Or maybe as Anne suggests for greater accessibility, you could also link to a text file that explains (with more depth than the alt attribute can give) what this image is. My criticism with this whole thing is that I in some ways like to know whether a certain URI is pointing to an image or a text document. This would probably be apparent from the circumstances of its use though (being placed in the src attribute of an img element, etc.).

This leads to a problem. If you had an image with the same filename as a document (and both did not have an extension), then which file does the server think the visitor is requesting? An obvious solution is to prefix the URI for all images with /image/ or similar. This would not have to be done within the file structure if not wanted. This of course over-rules my above criticism.

On Language Selection

Assume that you want to serve your site in several different languages. There have been several suggestions as to how you do this (for a french translation):

1. example.com/page.fr
2. example.com/fr/page
3. fr.example.com/page

I think that the latter idea is best. The first could lead to confusion between language and file type, which cannot be good. The second is acceptable, but I just prefer the third, probably for aesthetic reasons. Of course one would then presumably want to translate page into its meaning in that particular language, which would likely require characters not allowed in URIs, and thus IRIs would be required. I won’t go into that here though.

You can or course map example.com to the default subdomain, say en.example.com.

HTT What??

I really dislike http://. Not only is it a pain to say (though I so rarely do), but it also makes your URI technology-specific. What happends when we stop using HTTP; do all our URIs become uncool? Personally I think that all domains without the http:// prefix should for the time being be automatically remapped to having the http:// prefix (but hidden from the client end). Then we could all forget about HTTP, and when the time did come to use something else our cool URIs would still be cool! This may be more of a wish than an idea..

Well, I think that concludes my little rant for now. Phew!