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.<p>It can be much worse though...exposing machine names, unnecessary complexity and parameters, all changing from year to year.<p>A server doesn't <i>have</i> 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).<p>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 <i>how to find something</i> because the damn URL is unreliable.
Not only has the URL to that page not changed in 13 years, its content hasn't either. <a href="http://web.archive.org/web/19990508205057/http://www.w3.org/Provider/Style/URI.html" rel="nofollow">http://web.archive.org/web/19990508205057/http://www.w3.org/...</a>
I'm not sure if you did it on purpose, but<p><a href="http://www.w3.org/Provider/Style/URI" rel="nofollow">http://www.w3.org/Provider/Style/URI</a><p>works and is more in the spirit of the article than<p><a href="http://www.w3.org/Provider/Style/URI.html" rel="nofollow">http://www.w3.org/Provider/Style/URI.html</a>
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 <a href="http://www.w3.org/Provider/Style/URI.html" rel="nofollow">http://www.w3.org/Provider/Style/URI.html</a> to <a href="http://www.w3.org/blogs/articles/URI.html" rel="nofollow">http://www.w3.org/blogs/articles/URI.html</a> (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.
It's somewhat ironic that this was submitted as <a href="http://www.w3.org/Provider/Style/URI.html" rel="nofollow">http://www.w3.org/Provider/Style/URI.html</a> rather than <a href="http://www.w3.org/Provider/Style/URI" rel="nofollow">http://www.w3.org/Provider/Style/URI</a>.
Just saw another classic in the comments of a different story:<p>Top 10 mistakes of Web design
<a href="http://www.useit.com/alertbox/9605.html" rel="nofollow">http://www.useit.com/alertbox/9605.html</a><p>More classics anybody?
HN, what is going on here? Why are the four comments which disagree with the article (including my comment) all being <i>downvoted</i>?<p>Downvotes are for comments that don't contribute, not comments you disagree with.
The problem is that given enough time, the URL <i>will</i> 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.<p>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.
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.<p>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.<p>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.
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.<p>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.<p>It's incredibly unrealistic to expect every URI to be permanent.
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.<p>- <a href="http://vimeo.com/34269615" rel="nofollow">http://vimeo.com/34269615</a><p>- <a href="http://longbets.org/601/" rel="nofollow">http://longbets.org/601/</a>
> <i>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.</i><p>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.<p>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.<p>(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.)
> If so, you chose them very badly.<p>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."