Cool URIs Don't Change (1998)

"The primary goal of a URI is to identify a resource. If the identifier changes, the link is broken."

In the early architecture of the web, a fundamental tension emerged between how we locate a resource and how we identify it. Tim Berners-Lee posits that the most effective Uniform Resource Identifiers (URIs) are those that remain constant over time, regardless of changes to the underlying technology or organizational structure.

The Fragility of Implementation-Based URIs

Many developers make the mistake of encoding the physical location or the software implementation into the URI. When the internal structure of a server changes, these URIs inevitably break.

Wrong approach: Make the URI reflect the file system.

Consider the following examples of "brittle" URIs:

• http://server.com/software/version1/page.html (Breaks when the software is updated to version 2).
• http://server.com/users/john/public_html/index.html (Breaks if John moves his files or changes his username).
• http://server.com/cgi-bin/script.pl (Breaks if the script is rewritten in Python or Java).

The Cost of Link Rot

The "cost" of changing a URI is not just the time it takes to move a file, but the cumulative loss of all external references. We can represent the total impact of a URI change as:

$\text{Total Cost} = \sum_{i=1}^{n} (\text{Broken Link}_i \times \text{Traffic Loss}_i)$

Where $n$ is the number of external sites linking to the resource. Because the creator of a resource has no control over who links to it, the cost of a change is often unpredictable and potentially catastrophic.

Robust vs. Brittle Identifiers

To avoid these pitfalls, we must decouple the identifier from the location.

The Concept of Opacity

The ideal URI is opaque. This means the URI does not reveal anything about how the resource is stored or served. For example, instead of .../docs/manual/chapter1.html, a robust URI might look like .../doc/12345.

The Workflow of Resolution

When a user requests a robust URI, the server performs a mapping process to find the current physical location of the resource.

The Role of Redirection

While the goal is to never change a URI, reality sometimes forces a move. In these cases, HTTP redirection (like the 301 Moved Permanently status) is a useful tool. However, redirection is a patch, not a design philosophy.

If you rely solely on redirects, you create a "redirection chain" that increases latency and introduces more points of failure.

Example: Implementing a Redirect

In an .htaccess file, a redirect might look like this:

# Redirecting an old brittle URI to a new stable one
Redirect 301 /old-software/v1/page.html /stable/resource/123

Summary Checklist for URI Design

To ensure your resources remain discoverable for decades, follow these guidelines:

• Avoid including software versions in the path.
• Avoid including specific file extensions (e.g., .asp, .php, .html).
• Avoid including usernames or temporary directory names.
• Use abstract identifiers that map to resources internally.
• Prioritize stability over "human-readable" file paths.

In conclusion, the web's strength lies in its interconnectedness. By treating URIs as permanent identifiers rather than temporary addresses, we preserve the integrity of the global information web. Cool URIs don't change.