Love it or hate it URL shorteners are here to stay. Here is a draft proposal for a simple spec that would allow them to play nice with sites that already have their own short URLs
Very interesting proposal here... though I think having the consumer do an http request to get the "link" from HEAD is a bit too much to ask, for a few reasons:<p>* It takes bandwidth<p>* It's (presumably) before a pageload, and is blocking...
the latency to load the original URL to get the "link" gets added to the consumer's pageload time.<p>* Now you have to deal with "timeouts"<p>Ideally, "link" should be used by the browser, and not the web service. By the way, other such auto-discovery systems are OpenSearch (first proposed by Amazon, and is pretty widely adopted) and FavIcon.<p>At any rate, I think tinyurl, and bit.ly, etc, are a pretty fast and easy solution at this point. They should improve their services by including a "title" attribute to the link they give you, which says the URL and/or page title it's going to.
So is it short_url or short_uri or short-url or short-uri or "short url" or "short uri" or shorturl or shorturi?<p>"shortlink (<a href="http://code.google.com/p/shortlink/" rel="nofollow">http://code.google.com/p/shortlink/</a>) doesn't have any of the disadvantages of its predecessors...<p>Sam