Author — Sir Tim Berners-Lee, inventor of URI, URL, HTTP, HTML, and the World Wide Web, current head of W3C. The article was written in 1998

What makes a URI 'cool'?
One that does not change.
How do URIs change?
URIs do not change: people change them.

In theory, people have no reason to change URIs (or stop maintaining documents), but in practice, there are millions of reasons.

Theoretically, the nominal owner of a domain name space indeed owns that space and, consequently, all URIs within it. Except for insolvency, nothing prevents the domain name owner from retaining that name. And theoretically, the URI space under your domain name is completely under your control, so you can make it as stable as you like. To a significant extent, the only plausible reason for a document to disappear from the internet is that the company that owned the domain name went out of business or can no longer afford to maintain the server. So why are there so many broken links in the world? Partly it's just a lack of foresight. Here are some reasons you might hear:

We just reorganized the site to make it better.

Do you really think that old URIs can no longer work? If so, then you picked them very poorly. Consider making sure the new ones are preserved after the next redesign.

We have so much material that we can't keep track of what's outdated, what's confidential, and what's still relevant, so we figured it would be better to just turn it all off.

I can only sympathize. W3C went through a period where we had to carefully sift through archived materials for privacy concerns before making them public. The decision needs to be made in advance — ensure that you record an acceptable audience, creation date, and ideally, expiration date with each document. Preserve that metadata.

Well, we found out we need to move the files...

This is one of the lamest excuses. Many don’t realize that web servers allow you to manage the relationship between a URI of an object and its actual location in the file system. Imagine the URI space as an abstract realm, perfectly organized. Then map it to any reality you are actually using to implement it. Finally, inform the web server about this. You can even write a snippet of your server to get everything right.

John no longer maintains this file; now Jane does.

Was John's name in the URI? No, the file was just in his directory. Well, that makes sense.

We used to use a CGI script for this, but now we use a binary program.

There’s a crazy idea that pages generated by scripts should be located in the "cgibin" or "cgi" area. This exposes how you run your web server. Change the mechanism (even while keeping the content), and oops — all your URIs change.

Let’s take, for example, the National Science Foundation (NSF):

NSF online documents

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

The first page to start viewing documents clearly won’t remain that way in a few years. cgi-bin, oldbrowse and pl — all of this gives fragments of information about how-we-do-it-now. If you use a page to search for a document, you receive just as poor results first:

Cryptography and Coding Theory Working Group Report

http://www.nsf.gov/cgi-bin/getpub?nsf9814

for the document's index page, although the HTML document itself looks much better:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Here, the title pubs/1998 will give any future archival service a good key to understand that an old classification scheme from 1998 is in effect. Although in 2098 document numbers may look different, I can imagine that this URI will still be valid, and it won’t hinder NSF or any other organization that will maintain the archive.

I didn’t think that URLs needed to be permanent — there were URNs.

This is probably one of the worst side effects of discussing URNs. Some think that because of research into a more permanent namespace, they can be careless about dangling links since "URNs will fix all this." If you are one of these people, allow me to disappoint you.

Most of the URN schemes I have seen look like an authority identifier followed by either a date and a string of your choice or just a string of your choice. This is very similar to an HTTP URI. In other words, if you believe your organization will be able to create long-lasting URNs, then prove it now by using them for your HTTP URIs. There is nothing in HTTP that makes your URI unstable. Only your organization can do that. Create a database that maps the document's URN to its current file name, and let the web server use it to actually retrieve the files.

If you've made it this far, then if you don't have the time, money, and connections to develop any software, you can state the following excuse:

We wanted to, but we simply don't have the necessary tools.

And one can feel sorry for that. I completely agree. What you need to do is get the web server to instantly process the persistent URI and return the file, wherever it may currently reside in your current crazy file system. You want to store all URIs in a file as a check and continually maintain a database according to its relevance. You want to preserve the relationships between different versions and translations of the same document, as well as keep an independent checksum record to ensure protection against file corruption due to accidental errors. And web servers simply do not come out of the box with these features. When you want to create a new document, your editor asks for a URI.

You need the ability to change ownership, access to the document, archival-level security, and more in the URI space without changing the URI.

It’s all too bad. But we will fix it. At W3C, we use the functionality of Jigedit (the Jigsaw server for editing), which tracks versions, and we are experimenting with document creation scripts. If you are developing tools, servers, and clients, pay attention to this issue!

This excuse also applies to many W3C pages, including this one: so do what I say, not what I do.

Why should I care?

When you change the URI on your server, you can never fully say who will have links to the old URI. These can be links from regular web pages, bookmarks to your page, or a URI scribbled in the margins of a letter to a friend.

When someone clicks a link and it's broken, they usually lose trust in the server owner. They are also disappointed—both emotionally and practically—by the inability to reach their goal.

Many people constantly complain about broken links, and I hope the damage is clear. I also hope the reputational damage to the server maintainer, where the document has disappeared, is equally obvious.

So what should I do? Design URIs.

It's the webmaster's duty to design URIs that can be used in two years, in twenty years, and even in two hundred years. This requires thoughtfulness, organization, and determination.

URIs change when any information within them changes. It's very important how you design them. (What, design URIs? Do I need to design URIs? Yes, you should think about it). Designing essentially means leaving out any information from the URI.

The creation date of the document—the date the URI is issued—is something that will never change. It is very useful for differentiating requests that use the new system from those using the old system. It’s a good starting point for a URI. If the document has a date attached, even if it will remain relevant in the future, that’s a good place to start.

The only exception is a page that is intentionally the 'last' version, such as for an entire organization or a large part of it.

http://www.pathfinder.com/money/moneydaily/latest/

This is the last column of Money Daily in the Money magazine. The main reason why this URI doesn’t need a date is that there’s no reason to keep the URI that will outlive the magazine. The concept of Money Daily will disappear when Money ceases to exist. If you want to reference the content, it should be referenced separately in archives:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Looks good. Assumes that 'money' will mean the same throughout the existence of pathfinder.com. There’s duplication of '98' and unnecessary '.html', but otherwise it looks like a strong URI.

What to leave aside

Everything! Besides the creation date, putting any information in the URI invites problems in one way or another.

Author's nameAuthorship can change with the release of new versions. People leave organizations and hand things over to others.
SubjectIt's very difficult. It always looks good initially, but changes surprisingly quickly. I'll explain more about this below.
StatusCatalogs like 'old', 'draft', and so on, not to mention 'latest' and 'cool', appear in all file systems. Documents change status — otherwise, there's no point in creating drafts. The latest version of a document needs a constant identifier, regardless of its status. Keep the status out of the name.
AccessAt W3C, we divided the site into sections for employees, members, and the public. It sounds good, but of course, documents start as team ideas from employees, are discussed with members, and then become public. It's truly frustrating if every time a document opens for broader discussion, all old links to it break! Now we move on to a simple date code.
File extensionIt's a very common phenomenon. "cgi", even ".html" will change in the future. Perhaps in 20 years you won't be using HTML for this page, but today's links to it still need to work. Canonical links on the W3C site do not use extensions (how to do this).
Software mechanismsIn the URI, look for "cgi", "exec", and other terms that scream 'look at what software we use'. Does anyone want to dedicate their life to Perl CGI scripts? No? Then remove the .pl extension. Read the server manual on how to do this.
Drive name. Come on! But I've seen that.

So the best example from our site is simply

http://www.w3.org/1998/12/01/chairs

... the minutes report from the W3C chair meetings.

Topics and classification by topics

I will elaborate more on this danger, as it is one of the hardest things to avoid. Generally, themes end up in the URI when you classify your documents by the work performed. But this breakdown will change over time. Area names will change. At W3C, we wanted to transition from MarkUP to Markup, and then to HTML, to reflect the actual content of the section. Furthermore, there is often a flat namespace here. A hundred years from now, are you sure you won't want to reuse anything? In our short lives, we have already wanted to reuse 'History' and 'Style Sheets', for example.

It's an enticing way to organize a website—and indeed an attractive way to organize anything, including the entire web. It's a great medium-term solution but has serious drawbacks in the long term.

Part of the reasons lies in the philosophy of meaning. Each term in a language is a potential clustering object, and every person may have a different understanding of what it means. Since relationships between subjects are more like a web than a tree, even those who agree on the web might choose a different tree representation. These are my (often repeated) general comments on the dangers of hierarchical classification as a one-size-fits-all solution.

In fact, when you use a theme name in the URI, you tie yourself to a certain classification. You may prefer a different one in the future. Then the URI will be subject to disruption.

The reason for using a thematic area as part of the URI is that the responsibility for the subdivisions of the URI space is typically delegated, and then you need the name of the organizational body—a department, group, or something else that is responsible for that subspace. This ties the URI to the organizational structure. Typically, it is safe only when further (to the left) the URI is secured by a date: 1998/pics might mean to your server 'what we meant in 1998 by pics,' not 'what in 1998 we did with what we now call pics.'

Don't forget the domain name

Remember that this applies not only to the path in the URI but also to the server name. If you have separate servers for different purposes, keep in mind that this separation will be impossible to change without destroying countless links. Some classic mistakes like "look at the software we are using today" — domain names "cgi.pathfinder.com", "secure", "lists.w3.org". They are designed to facilitate server administration. Regardless of whether the domain represents a division in your company, document status, access level, or security level, be very, very careful before using more than one domain name for multiple types of documents. Remember that you can hide many web servers behind one visible web server using redirection and proxying.

Yes, and think about your domain name as well. You don't want to be referred to as soap.com after you change your product line and stop making soap (Apologies to whoever owns soap.com at the moment).

Conclusion

Maintaining a URI for 2, 20, 200, or even 2000 years is clearly not as easy as it seems. However, throughout the internet, webmasters make decisions that truly complicate this task for themselves in the future. Often this happens because they use tools whose purpose is to present the best website only at the moment—and no one has considered what will happen to the links when everything changes. However, the point here is that a lot, a lot can change, and your URIs can and should remain the same. This is only possible when you think about how you create them.

Additions

How to remove file extensions...

...from URIs in the current web server based on files?

If you are using, for example, Apache, you can configure it to negotiate content. You keep the file extension (e.g., .png) in the file (e.g., mydog.png), but you can reference a web resource without it. Then Apache checks the directory for all files with this name and any extension, and can choose the best from the set (for example, GIF and PNG). There's no need to place different file types in separate directories; indeed, content negotiation won't work if you do that.

Configure your server for content negotiation
Always link to URIs without extensions

Links with extensions will still work, but will not allow your server to choose the best format available now and in the future.

(In fact, mydog, mydog.png and mydog.gif — valid web resources, mydog — is a resource of a universal content type, and mydog.png and mydog.gif — resources of a specific content type).

Of course, if you are writing your own web server, it would be nice to use a database to bind permanent identifiers to their current form, although beware of uncontrolled database growth.

Hall of Shame — Story 1: Channel 7

Throughout 1999, I was tracking school closures due to snow on the page http://www.whdh.com/stormforce/closings.shtml. You can't just wait for information to appear at the bottom of the TV screen! I linked to it from my homepage. The first major snowstorm of 2000 hits, and I check the page. It says:

— As of.
Currently, nothing is closed. Please check back for weather alerts.

Can't be, such a strong storm. Interestingly, the date is missing. But if you go to the homepage of the site, there will be a big button 'Closed Schools' leading to a page http://www.whdh.com/stormforce/ with a long list of closed schools.

Maybe they changed the system for retrieving the list — but they didn't need to change the URI.

Hall of Shame — Story 2: Microsoft Netmeeting

With the growing dependence on the Internet came the clever idea of embedding links to the manufacturer's site in applications. This was often done and greatly abused, but — you can't change the URL. Just the other day, I tried a link from Microsoft Netmeeting 2/something in the Help/Microsoft on the Web/Free stuff menu and got a 404 error — server not found. Maybe they fixed it already...

Historical note: at the end of the 20th century, when this was written, "cool" was an epithet of approval, especially among youth, indicating trendiness, quality, or relevance. In haste, URI paths were often chosen for their "coolness" rather than usefulness or durability. This note is an attempt to redirect the energy behind the quest for coolness.

Source: habr.com