9 ms·

Cool URIs don't change.

187 points by diwank 14y ago

mef 14y 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/Provider/Style/URI.html http://web.archive.org/web/19990508205057/http://www.w3.org/...
- technel 14y ago
  I had a number of revelations through rereading this classic article: First, holy crap, I hadn't been to http://www.w3.org/ 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 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 14y ago
    > Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html 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.
    - technel 14y ago
      Convention is for URLs to be all lowercase, which IMO aids in readability and certainly makes them easier to type (imagine giving a URL to a friend over the phone -- remember this is 1999).
      - deleted 14y ago
        [deleted]
      - porges 14y ago
        Well luckily for you, the URI is case-insensitive and redirects (301) to the canonical version.
      - dredmorbius 14y ago
        The standard is that hostnames are case-insensitive, but non-FQDN paths should allow both uppercase (especially for systems which don't include lower-case elements, yes, Virginia, they exist) and lowercase elements.
    - einhverfr 14y ago
      like_using_method_names_like_this is more readable. White space has been in use to separate words since the time of Alciun, and that's the closest way to do it. Call me conservative but I prefer to stick to the insights of the last 1400 years rather than mangle them horribly ;-) Oh, and I am not a Ruby developer ;-)
      - Dylan16807 14y ago
        Whitespace is nice but underscores aren't whitespace. They also leave a zigzag effect that isn't wonderful.
        einhverfr 14y ago
        They are the closest thing you can have to whitespace. That's the point. Actually come to think of it, they are underlined whitespace ;-) As for a zigzag effect I think CamelCasing is at least that bad, maybe moreso. Wondering if I get points for bringing early Medieval history into a discussion on coding conventions ;-)
        rrreese 14y ago
        What do you mean by zigzag effect?
        batista 14y ago
        The it isn't actually word+empty-space+word but word+line-down-below+word so your eyes go zig-zag from the taller glyphs of the word to the low glyph of the underscore (vertical zig zag motion), instead of jumping to the next world (horizontal).
        einhverfr 14y ago
        funny, I was just checking because I have never noticed my eyes doing that and afaics my eyes still scan horizontally. I don't need to look down to see the underscore. I guess YMMV?
    - kalininalex 14y ago
      I agree that method_names_like_this is more readable, even (or, especially) after many years of .NET programming. I used the_style_like_this back in C++ days and, honestly, miss it. Perhaps, the renaissance of C++ in the form of C++11 will bring it back :)
    - beefsack 14y ago
      Actually I read somewhere that the decision for Ruby using underscored names as a naming convention was because of the very large number of non-native English speakers in the early days of the language. Something along the lines of it was easier to read for non-native speakers because it more closely mimicked spaced English. Searching for the source now.
  - lifthrasiir 14y 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 14y ago
    > Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html 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."
einhverfr 14y 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 14y 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?
  - einhverfr 14y 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 14y ago
I'm not sure if you did it on purpose, but http://www.w3.org/Provider/Style/URI 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 http://www.w3.org/Provider/Style/URI.html
- mkopinsky 14y ago
  However, http://www.w3.org/Provider/Style/URI/ 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 14y ago
    That's not true everywhere. For example, http://en.wikipedia.org/wiki/Wikipedia/ http://en.wikipedia.org/wiki/Wikipedia/.
    - notatoad 14y ago
      Obviously it isn't true everywhere, it's a convention not a hard rule. If Wikipedia were friendlier they'd do a redirect there instead of 404-ing.
      - m_for_monkey 14y ago
        There's a reason: http://en.wikipedia.org/wiki// http://en.wikipedia.org/wiki// http://en.wikipedia.org/wiki/// http://en.wikipedia.org/wiki///
  - alanh 14y 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 http://alanhogan.com/url-as-ui
crazygringo 14y 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.)
- alanh 14y 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.
  - vdm 14y 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.
bradwestness 14y 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.
- alanh 14y 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.
  - bradwestness 14y 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.
yaix 14y 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 http://www.useit.com/alertbox/9605.html More classics anybody?
- TeMPOraL 14y 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 14y 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.
- simonw 14y 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.
  - kree10 14y 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 http://example.com/x/index.html and http://example.com/x/about.html 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.
kevinsd 14y ago
It is like asking a developer not to change API. Or keep the old version.
- noamsml 14y 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 14y 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 14y 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.
willsulzer 14y 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 http://www.w3.org/Provider/Style/URI.html to http://www.w3.org/blogs/articles/URI.html 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.
robbiemitchell 14y 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."
Sambdala 14y ago
It's somewhat ironic that this was submitted as http://www.w3.org/Provider/Style/URI.html http://www.w3.org/Provider/Style/URI.html rather than http://www.w3.org/Provider/Style/URI http://www.w3.org/Provider/Style/URI.
crazygringo 14y 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 14y 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://vimeo.com/34269615 - http://longbets.org/601/ http://longbets.org/601/
mindslight 14y ago
And the coolest URIs can't change.

187 points by diwank 14y ago

mef 14y 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/Provider/Style/URI.html http://web.archive.org/web/19990508205057/http://www.w3.org/...

technel 14y ago
I had a number of revelations through rereading this classic article: First, holy crap, I hadn't been to http://www.w3.org/ 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 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 14y ago
  > Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html 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.
  - technel 14y ago
    Convention is for URLs to be all lowercase, which IMO aids in readability and certainly makes them easier to type (imagine giving a URL to a friend over the phone -- remember this is 1999).
    - deleted 14y ago
      [deleted]
    - porges 14y ago
      Well luckily for you, the URI is case-insensitive and redirects (301) to the canonical version.
    - dredmorbius 14y ago
      The standard is that hostnames are case-insensitive, but non-FQDN paths should allow both uppercase (especially for systems which don't include lower-case elements, yes, Virginia, they exist) and lowercase elements.
  - einhverfr 14y ago
    like_using_method_names_like_this is more readable. White space has been in use to separate words since the time of Alciun, and that's the closest way to do it. Call me conservative but I prefer to stick to the insights of the last 1400 years rather than mangle them horribly ;-) Oh, and I am not a Ruby developer ;-)
    - Dylan16807 14y ago
      Whitespace is nice but underscores aren't whitespace. They also leave a zigzag effect that isn't wonderful.
      - einhverfr 14y ago
        They are the closest thing you can have to whitespace. That's the point. Actually come to think of it, they are underlined whitespace ;-) As for a zigzag effect I think CamelCasing is at least that bad, maybe moreso. Wondering if I get points for bringing early Medieval history into a discussion on coding conventions ;-)
      - rrreese 14y ago
        What do you mean by zigzag effect?
        batista 14y ago
        The it isn't actually word+empty-space+word but word+line-down-below+word so your eyes go zig-zag from the taller glyphs of the word to the low glyph of the underscore (vertical zig zag motion), instead of jumping to the next world (horizontal).
        einhverfr 14y ago
        funny, I was just checking because I have never noticed my eyes doing that and afaics my eyes still scan horizontally. I don't need to look down to see the underscore. I guess YMMV?
  - kalininalex 14y ago
    I agree that method_names_like_this is more readable, even (or, especially) after many years of .NET programming. I used the_style_like_this back in C++ days and, honestly, miss it. Perhaps, the renaissance of C++ in the form of C++11 will bring it back :)
  - beefsack 14y ago
    Actually I read somewhere that the decision for Ruby using underscored names as a naming convention was because of the very large number of non-native English speakers in the early days of the language. Something along the lines of it was easier to read for non-native speakers because it more closely mimicked spaced English. Searching for the source now.
- lifthrasiir 14y 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 14y ago
  > Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html 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."

einhverfr 14y 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 14y 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?
- einhverfr 14y 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 14y ago

I'm not sure if you did it on purpose, but http://www.w3.org/Provider/Style/URI 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 http://www.w3.org/Provider/Style/URI.html

mkopinsky 14y ago
However, http://www.w3.org/Provider/Style/URI/ 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 14y ago
  That's not true everywhere. For example, http://en.wikipedia.org/wiki/Wikipedia/ http://en.wikipedia.org/wiki/Wikipedia/.
  - notatoad 14y ago
    Obviously it isn't true everywhere, it's a convention not a hard rule. If Wikipedia were friendlier they'd do a redirect there instead of 404-ing.
    - m_for_monkey 14y ago
      There's a reason: http://en.wikipedia.org/wiki// http://en.wikipedia.org/wiki// http://en.wikipedia.org/wiki/// http://en.wikipedia.org/wiki///
- alanh 14y 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 http://alanhogan.com/url-as-ui

crazygringo 14y 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.)

alanh 14y 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.
- vdm 14y 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.

bradwestness 14y 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.

alanh 14y 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.
- bradwestness 14y 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.

yaix 14y 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 http://www.useit.com/alertbox/9605.html More classics anybody?

TeMPOraL 14y 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 14y 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.

simonw 14y 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.
- kree10 14y 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 http://example.com/x/index.html and http://example.com/x/about.html 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.

kevinsd 14y ago

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

noamsml 14y 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 14y 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 14y 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.

willsulzer 14y 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 http://www.w3.org/Provider/Style/URI.html to http://www.w3.org/blogs/articles/URI.html 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.

robbiemitchell 14y 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."

Sambdala 14y ago

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

crazygringo 14y 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 14y 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://vimeo.com/34269615 - http://longbets.org/601/ http://longbets.org/601/

mindslight 14y ago

And the coolest URIs can't change.