Don’t change URLs, ever
I have a bookmark which I check every other day on my data plan usage. After I got back from CNY, I realize it didn’t work anymore. Turns out that the URL has been changed from
http://www.ideas.singtel.com/BOM/HS_usage02.jsp?mobile=65<YourPhoneNumber>&ic=<YourICNumber>
to
http://apps.ideas.singtel.com/BOM/HS_usage02.jsp?mobile=65<YourPhoneNumber>&ic=<YourICNumber>
Don’t do this, please. URLs are supposed to be well known. It’s hard for people to build useful applications if small things like these keep changing. If there’s a data interface (XML or whatnot), then make it known. Otherwise, a simple google search will reveal that the many help given on forums / blogs / etc. are now broken and useless.
If it’s a load issue, then one can put in better load-balancers facing the same www domain name (or just put a few more IP for DNS round robin to kick in). This gives maximum flexibility while retaining the same URL for all your consumers. Some layer 7 LBs can read HTTP headers / URLs and redirect according to a set of rules pretty quickly.
And even if there’s a need to switch, then do something to give a good response instead of just moving it. This is what www is saying:
Error 404–Not Found
From RFC 2068 Hypertext Transfer Protocol — HTTP/1.1:
10.4.5 404 Not FoundThe server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
It’s funny now the customers are being lectured by the server.
that’s the thing i hate about changing url address. All the link will be broken… have to restart from scratches again =)
Ironically I’ve just arrived here after reading Coding Horror’s latest article that says:
“Never? Ever? Never ever ever? Not even once? Not even if it doesn’t matter? Any time you see “don’t ever do X”, alarm bells should be going off. Like they hopefully are right now. ”
http://www.codinghorror.com/blog/archives/001218.html
I am of the opinion that URL can be changed, provided that that the old link works, or at least redirected. Error 404 is, of course, unacceptable. Telling the visitor that the page has moved isn’t too helpful either (try http://msdn.microsoft.com/netframework/programming/bcl/faq/StringFormattingFAQ.aspx )
Recently, I’ve changed my wordpress permalinks structure to look more “friendly” (you should too). And the first thing that came to my mind is what will happened to all the old links (one of them is in http://wp.jiinjoo.com/?p=445 ). Glad I found Dean’s Permalinks Migration that ensures all new and old permalinks works.
I heart wordpress. :D.
Oh just so u know, I’ve used my precious quota time here instead of my RSS reader because wp.jiinjoo.com is categorized by the Websense as “Social Networking and Personal Sites”, which is filtered.
Clock is ticking.
Ya but you also forgot that the purpose of the unfriendly URLs and explicit categorization (I did it myself through DMOZ) is so that it doesn’t get too much attention. I do friendly URLs for every other wordpress projects I run.
In this case I’m sticking to “never” for the case of URLs (Coding horror is talking about “machine” optimization at the miliseconds – I’m talking about Human, and it’s not your organization but the entire world). Btw, “don’t ever” also gets people to read your blog 😉 But what I meant was don’t ever if you can afford not to, as a principle, not like a crime. So it’s as a principle that I’m not changing 445 to something else, because when it’s published, it’s published (it’s in every single aggregator, people start hyperlinking on their blogs, etc.)
Aside: Here’s the classic TBL’s take on this issue, in case you haven’t seen it:
http://www.w3.org/Provider/Style/URI
Cool URI’s don’t change
Great, heard that they also got cert mismatch problems when access through https…