Cool URIs don't change.

http://www.w3.org/Provider/Style/URI.html

by diwank • 14 years ago

187 84 14 years ago

mef• 14 years ago

Not only has the URL to that page not changed in 13 years, its content hasn't either. http://web.archive.org/web/19990508205057/http://www.w3.org/...

technel2• 14 years ago

I had a number of revelations through rereading this classic article:

First, holy crap, I hadn't been to http://www.w3.org/ in a long time, and it looks like they've actually made it to the 21st century!

Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html is kind of an unfortunate URI. What's "Provider"? Why are "Provider" and "Style" uppercase? And what's wrong with 301 redirecting (don't break old URIs, but still restructure them as your website matures and you realize a better organizational hierarchy)?

Third and perhaps most importantly, this all seems like a pretty awesome problem to have! How many websites survive more than a few years? (Geocities doesn't count.)

charliesome• 14 years ago

> Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html is kind of an unfortunate URI. What's "Provider"? Why are "Provider" and "Style" uppercase?

They're uppercase because they're uppercase. Asking why is like asking why Rubyists like_using_method_names_like_this and .NET devs LikeUsingMethodNamesLikeThis.

lifthrasiir• 14 years ago

> What's "Provider"?

It's because it is a part of a collection of numerous pages named "Putting Information onto the Web". Its audience is obviously (content) providers, which the URI reflects.

primatology• 14 years ago

> Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html is kind of an unfortunate URI. What's "Provider"? Why are "Provider" and "Style" uppercase?

Take a look at w3.org/Provider and w3.org/Provider/Style. It's actually a well-constructed URL. It appears to be a "Style guide" for "web content Providers."

einhverfr5• 14 years ago

Some of it depends on the nature of the URI though. The article is about linked resources, but a lot of URI usage isn't really about linked resources. Many of these can change reasonably.

For example, is there any harm in changing where that contact us form points to? Do you have to maintain the contact us forms API to be backwards compatible forever? This really depends on what you are doing.

I agree with the article as it relates to documents for the most part. There are cases where maintaining URL backwards compatibility is a problem due to unforeseen dead ends. However, for the most part it shouldn't be. However, URIs needs for persistence varies so widely that I don't know one can generalize much beyond that.

alexmuller• 14 years ago

> For example, is there any harm in changing where that contact us form points to?

The point could more be made: "Why not keep that URL the same?"

It's trivial to do technically, and there's no advantage to be had from moving back and forth between foo.com/contact and foo.com/contact-us. If the URL of your company's contact form gets published in a book, would that change your mind?

einhverfr5• 14 years ago

Sorry I was misunderstood. I was talking about the URL where the form is submitted, not the URL of the form. For the URL of the form, it's generally desirable to keep it the same all things being equal because this doesn't break other people's links.

But where it is a form submission target, the only reason to care is if you are accepting third party form submission. But we are no longer talking about hypertext resources at that point which is my main point.

AntiRush• 14 years ago

I'm not sure if you did it on purpose, but

http://www.w3.org/Provider/Style/URI

works and is more in the spirit of the article than

http://www.w3.org/Provider/Style/URI.html

mkopinsky• 14 years ago

However, http://www.w3.org/Provider/Style/URI/ does not work. I guess this makes some sense, but certainly violates the "typical" functionality on the web where trailing slashes are ignored.

dullcrisp• 14 years ago

That's not true everywhere. For example, http://en.wikipedia.org/wiki/Wikipedia/.

alanh4• 14 years ago

Agreed. That’s a rule I mention in my piece, “URL as UI”, which I really want everyone to read. (If it feels like self-promotion, then please kindly ignore my username / blog masthead. I only care about these ideas.) http://alanhogan.com/url-as-ui

Zr40• 14 years ago

Actually, this behavior you're referring to is a combination of trying to access a directory (to which a missing trailing slash is automatically appended) and the use of default pages (for Apache, that's the DirectoryIndex directive). Trailing slashes on files is not valid, because files are not directories.

s00pcan• 14 years ago

http://www.w3.org/Provider/Style/URI.anything gives a menu of available extensions to choose from. For example, html.es for spanish.

crazygringo2• 14 years ago

> Pretty much the only good reason for a document to disappear from the Web is that the company which owned the domain name went out of business or can no longer afford to keep the server running. Then why are there so many dangling links in the world? Part of it is just lack of forethought.

Nope, it's the lack of a crystal ball. The technology world moves fast. And breaks things, as Zuck says. I have no idea how a site of mine might be structured even a year from now, and if the currently URL scheme will conflict directly with its needs or not, or if an old-to-new translation will be trivial or overly resource-intensive. By now, the world has mostly realized that over-planning is bad, and agile is important.

So who cares if a 5-year-old URL to a page virtually nobody ever visits anymore doesn't work. It's easy to Google the keywords in the link, and you'll probably be able to find the content if it's still around.

(Obviously big sites have an incentive to keep their links working, but they don't need an article from the W3C to tell them that.)

alanh4• 14 years ago

Oh, so you are the guy who has been causing all those 404s that I bump into.

And nice strawman, by the way. I have had some EXTREMELY popular blog posts that I bookmarked (remember NVIE’s post on git branching?) 404 just because the site changed architecture. (Now hosted on GitHub.) It’s all laziness and lack of forethought and planning. What is agile about one of the most popular blog posts in the development world 404ing?

That said, yes, it can be a bit time-consuming to map old URLs to new. I once started a project that would help considerably with this, but my employer at the time decided it wasn’t worth it (hey, would they see any more gold coins if they helped clients’ visitors’ bookmarks and search results work?). But a manual connection isn’t impossible. In some cases, it’s easy. When I moved off Drupal (damn it to hell), I redirected all those old /node/<id> URLs to their new ones. Because, damn it, I wasn’t going to add any 404s to the Internet if I could. I didn’t blog to make money. I blogged to help people. And maintaining URLs helps people.

vdm2• 14 years ago

An interface where an admin can incrementally add redirect URLs directly in the 404 logs, to the top most frequent misses, would go a long way.

It's the UX inertia of having to write mod_rewrite rules that ensure its never a priority and thus never happens.

yaix2• 14 years ago

"technology world moves fast [...] currently URL scheme will conflict directly with its needs or not"

That is your mistake. The URI should be decoupled from the technology you are using. The URI is part of the content and not of the software behind the site.

alanh4• 14 years ago

Amen. A thousand times, amen.

If your stack requires tight coupling with URL structure, you have doomed yourself already.

hollerith• 14 years ago

And if you do not decouple them, users will be more likely to use 3rd party services to effect the decoupling.

bradwestness2• 14 years ago

Organizations with large websites use content management systems. Vendors of content management systems come and go as technology changes. Usually, changing the CMS a website uses necessitates URI structure changes depending on the conventions of the system.

Maintaining in perpetuity a complete set of redirects (or stack of rewrite rules) for every page for a website consisting of millions of pages for decades is not feasible in most cases. Things change, departments are created or disbanded or renamed. Management decides certain things should not be accessible to the public or stored in a particular location.

It's incredibly unrealistic to expect every URI to be permanent.

alanh4• 14 years ago

You are describing the status quo as you see it, as if it were a rebuttal to the ideal towards which we should be striving.

bradwestness2• 14 years ago

No, I'm saying that technology changes, the web changes, your organization changes and the content on the website changes. To act like it's even desirable to have all of the same documents at the same locations on your website in 20 years is misguided.

yaix2• 14 years ago

Just saw another classic in the comments of a different story:

Top 10 mistakes of Web design http://www.useit.com/alertbox/9605.html

More classics anybody?

TeMPOraL• 14 years ago

Good they mention "banner blindness" and related phenomena. I see webpages sometimes that make these mistakes, and once or twice I ever got burned by it - like when I missed a very important "Point 0" from some IRC channel's FAQ. This Point 0 was so important for channel mods, that they put it directly above the page headline, and I honestly didn't perceive it was there until I reread the page for the third time.

makecheck• 14 years ago

One thing that's always bugged me is file extensions...I hate having to type ".php" or ".cgi" or ".asp" or whatever else just happens to reflect the server's implementation at the time. If they switch from Microsoft to LAMP then their URLs will probably all break needlessly.

It can be much worse though...exposing machine names, unnecessary complexity and parameters, all changing from year to year.

A server doesn't have to puke its implementation details everywhere. I can't even count all the "enterprise" apps that make that mistake (e.g. a helpdesk system that gives me "serverNameThatWillChangeNextYear.domain.net/some/unnecessarily/convoluted/path.unnecessaryExtension?whatthehellisallthis&garbage1=a&garbage2=b&finallyRelevantBugNumber" instead of a stable URL like "company.net/bugs/bug123456". And just try E-mailing a complex URL to somebody (it wraps, and time is spent to awkwardly correct it).

Honestly, it's as if most web developers don't understand how powerful URLs can be. If you make URLs short and stable and use them to help look up stuff, they can be very nice. Instead in the past I've seen people E-mailing 9-step instructions on how to find something because the damn URL is unreliable.

dangrossman• 14 years ago

> Honestly, it's as if most web developers don't understand how powerful URLs can be.

Or, more likely, most of the "enterprise" apps with those URLs were first released over a decade ago, when the idea of "pretty URLs" was not yet mainstream. There was not even a mention of mod_rewrite on Wikipedia at that point. The article on the front controller pattern, which most webapps that handle their own URL routing use, wasn't written until 2008.

apike• 14 years ago

> most of the "enterprise" apps with those URLs were first released over a decade ago, when the idea of "pretty URLs" was not yet mainstream.

Or, even more likely, the enterprise customer never specified "URLs that aren't terrible" in their 100-page RFP, and so the lowest bidder didn't bother with URLs that aren't terrible.

dredmorbius9• 14 years ago

The first URLs were short and sweet.

HTML, and server paths / CGIs were largely hand-coded and short.

The URI explosion occurred in the late 1990s / early aughts for the most part with Java and Microsoft entering the fray from my recollection.

simonw2• 14 years ago

The thing that drives me up the wall is "index.html" - that's pretty much inexcusable in my opinion. There are even some sites where the root path on the domain REDIRECTS to example.com/index.html - don't do that.

kree102• 14 years ago

While seeing "index.html" (or "index.ANYTHING") makes me cringe, I have some sympathy for the developers who do this.

Let's say I have an old-school, all-static site with pages at http://example.com/x/index.html and http://example.com/x/about.html. I would like to make a link to the "index" page from the "about" page. What are my choices?

<a href="/x/"> will work, but will break when someone decides to move "/x" to "/y".

<a href="."> will work from the server, which does an internal redirect, but not on the static version on my local drive I'm going to demo to my boss. (I also have a hunch a significant number of developers aren't aware of "." and don't know this is an option.)

So we end up with <a href="index.html"> for better or worse.

andyjohnson03• 14 years ago

I don't get it - why is index inexcusable as part of a url?

readme• 14 years ago

When working with apache, one can use the option MultiViews to easily perform content negotiation without the file extension in the uri.

If I do find myself working with LAMP (which a lot of people still use) then I use this option, and my uris magically no longer end with ".php"

maigret• 14 years ago

Problem ist most companies don't have someone who actually owns the URL namespace. Or the engineer who wrote that bug reporting tool was too shy to contact the CIO, etc.

I agree with your point, but it's also valuable to understand the structural reasons that prevent such things.

porges2• 14 years ago

On a related tangent, can we please have an operating system that eschews extensions and instead stores the MIME type for each file?

rdl• 14 years ago

The crazy mac resource fork thing isn't exactly better.

kalleboo• 14 years ago

Mac OS X? http://en.wikipedia.org/wiki/Uniform_Type_Identifier

wmf• 14 years ago

BeOS did that. I think it's a shame that OS X seems to be moving backwards in this respect.

jamesbritt2• 14 years ago

Ugh. I have that in the konqueror file browser. It beleives that my .epub files are zip archives, so the default handler is not an epub reader.

dredmorbius9• 14 years ago

Do you mean default file magic: http://en.wikipedia.org/wiki/Magic_number_(programming)

Or do you mean storing a database of the application associated, specifically, with any given file (so that I might open, say, a given myprog.c with vi, emacs, or textmate)?

The Mac OS resource fork model attempts the second, but it's an inherently single-user concept that leaves artifacts around for other users and/or on shared media in an annoying way. A shadow filesystem maintained on a per-user basis under their control would be a preferred solution.

gioele• 14 years ago

Bright people use other people's problems to their advantage: in pg's viaweb they deliberately put extra `cgi-bin/` every here and there just to confuse their competitors.

http://news.ycombinator.com/item?id=4589

kree102• 14 years ago

I think some organizations see this kind of implementation leakage as a feature, not a bug.

I remember when http://microsoft.com/ began doing external redirects to "default.asp" circa 1997. If you were a "webmaster" (do these exist anymore?), this was a dog whistle. They were not using static .html (or .htm) but not any of the common dynamic methods like .cgi or .shtml either. And using "default" rather than "index" indicated a break from NCSA/Apache convention. They were using a different web server. Those 11 extra characters said a lot.

kevinsd• 14 years ago

It is like asking a developer not to change API. Or keep the old version.

noamsml• 14 years ago

And companies that have millions of developers making money off their APIs (and, in one way or another, paying some dividend back to the API creators) indeed do tend to keep their APIs fairly backwards-compatible, with some notable exceptions.

comex• 14 years ago

The problem is that given enough time, the URL will break-- you'll redo the entire site (a shiny new CMS/cloud provider/hosted solution/server!), or accidentally delete everything, or get hacked, or get acquired, or go out of business. Or even if you keep your important links up forever, various obscure bits and pieces will come and go, and years later, somebody will find an old link to one of them. Bitrot is a fundamental limitation of the web, and it sucks.

The workaround is the Wayback Machine, which is amazing, but could be more comprehensive and frequently updated. I wish someone like Google would throw more servers at it.

seldo• 14 years ago

The point of the article is that as long as you control the domain, you have no excuse for your links breaking. Going out of business, and therefore being unable to pay for your domain, is specifically called out as a valid reason, but there's no reason you'd lose control of your domain after being acquired, even if you decided to redirect your old links to newer information. Shiny new software is also specifically called out as a bad reason to break links, since backwards-compatible redirects are trivial. And if you're capable of permanently losing all your data through accidental deletion or a server being compromised, you have much bigger problems.

All that said, you're fundamentally right -- sometimes information stops being available because it's out of date, and keeping it available would be confusing (if a product is no longer available, it would be strange to maintain a page describing it for years afterwards). Archiving through the Wayback machine is a very helpful stopgap, but expecting them to continuously archive every version of the entire Internet for all time won't scale.

What's needed is a distributed, decentralized system, ideally at the protocol level. Imagine if a GET request by default gave you the "current" version of a page, but you could send an extra header that said "give me this page, as it appeared at date-time X". This would remove the confusion caused by the existence of a page being conflated with that page being current[1], and allow sites to maintain clean navigational and data structures by flagging outdated pages as "expired" instead of completely deleting them. When a server got a request for a page that used to but no longer exists, it could respond with a new 4xx-series header, "No longer current", indicating the document is not available for the given date-time, but is available for an earlier date.

[1] I frequently get people sending me ANGRY emails about flippant, immature blog posts I wrote 10+ years ago[2]. They assume that because it's still on my website, I still stand by those statements, when in fact I'm just reluctant to delete information.

[2] The posts still get traffic, because links to them made 10+ years ago still work, despite rewriting my CMS 3 times.

adavies422• 14 years ago

> What's needed is a distributed, decentralized system, ideally at the protocol level. Imagine if a GET request by default gave you the "current" version of a page, but you could send an extra header that said "give me this page, as it appeared at date-time X".

Sounds like Freenet USK's (see https://freenetproject.org/understand.html, search for USK (and boo on them for not having any anchors on that page)).

vdm2• 14 years ago

> an extra header that said "give me this page, as it appeared at date-time X"

It's your lucky day: http://www.mementoweb.org/

JadeNB• 14 years ago

> [1] I frequently get people sending me ANGRY emails about flippant, immature blog posts I wrote 10+ years ago[2]. They assume that because it's still on my website, I still stand by those statements, when in fact I'm just reluctant to delete information.

Couldn't you implement a clumsy manual version of the 'expired' header you're proposing, by doing something like having your server precede each page with "The following has not been modified since …, and should not be regarded as current" if it is more than a certain amount of time old?

willsulzer• 14 years ago

I agree with this article to the extent that we should choose our URIs carefully and semantically. However, it is very likely that your web facing application, and the semantics of your resources will change over time. What if I wanted to deprecate and eventually remove my 'Providor' or 'Style' resource? Maybe I decided to create a 'blogs' and an 'articles' resource. That would change the URI from http://www.w3.org/Provider/Style/URI.html to http://www.w3.org/blogs/articles/URI.html (I know that my choice of new resources aren't the most interesting but you get the point). Of course, we would still support the old URI via a 301 redirect to the new one, or continue to serve up the page from the old URI and use a rel canonical meta tag. I'd advocate for 301ing to the new URI and letting the past be the past. We shouldn't be bound to these decisions for the rest of our lives. Unless you're sure that the focus of your web app will never change, or you plan to build your new resource URIs around old resource URIs that were chosen at a time when your new resources weren't being considered (which would lead to far worse URIs), then I'd plan for your URIs to change.

Sambdala• 14 years ago

It's somewhat ironic that this was submitted as http://www.w3.org/Provider/Style/URI.html rather than http://www.w3.org/Provider/Style/URI.

crazygringo2• 14 years ago

HN, what is going on here? Why are the four comments which disagree with the article (including my comment) all being downvoted?

Downvotes are for comments that don't contribute, not comments you disagree with.

zmoazeni• 14 years ago

Jeremy Keith's talk and resulting long bet on the topic is interesting. He contends that it's not proven that data put on the internet is in fact immortalized.

- http://vimeo.com/34269615

- http://longbets.org/601/

mindslight• 14 years ago

And the coolest URIs can't change.

robbiemitchell• 14 years ago

> If so, you chose them very badly.

I love how this starts out by (wrongly) assuming that "you" is a single person or even stable group of people, and that the answer to a changing URI is to say "You did it wrong."

Cool URIs don't change.

Related Stories