Implementation

[Bernhard Häussner]

The keyword shortlink seems fine.
I would maybe advise for implementations:
- Use the header for faster resolving of shortended urls (Only HEAD
not GET)
- Use the <link> Tag too, for Javascript Auto-Discovery
- Best, include a <a> HTML-Link in your document and everyone will be
able to find the url.

Tricky:
- Anchors. Should the short URL be able to shorten an anchor too? This
might be impossible. (So shortened url discoverer should enable this?)
- Use 302 Redirect because the document will never be placed at the
short url

Maybe with this we can fight some of the link rot.

regards

[Sam Johnston]

Bernhard,

Thanks for the feedback. I forgot to mention before that I see two use cases: software such as Twitter clients that wants a lightweight way to resolve a given URL (canonical or otherwise) to a shorter URL in the fastest/most lightweight way possible and clients such as web browsers that have already rendered the page and want to extract a URL e.g. for posting to a microblogging service.

In the first case you don't have the content so you should use a HTTP HEAD request to check for the Link: header. This is fast, cheap and requires little work on the server side and little parsing on the client side. These clients should not retrieve the content unnecessarily - a lot of the time (at least at the start) the result will be negative and some other mechanism will have to be used (e.g. a "traditional" URL shortener). In the latter case we do have the content from which we can easily parse the <link> elements.

Anchors may or may not work (depending on the browser) if I understand well. As for 301 vs 302, I'd have thought 301 Moved Permanently would be more sensible, but it's not something I fully grok the implications of in this context just yet.

Sam