URL Shortening

{toc}
h1. Intro
The [Data Basket UI design] shows shortened URLs (eg "RS.ly/MK3CD").
Such functionality was not discussed in the spec, but was accepted as a given during the UI design discussion.
Here we will put the design decisions about how we'll implement URL shortening.

h1. Disadvantages
Shortened URLs have many disadvantages including unreadability, reduction of trust, instability, overhead traffic, and security risks.
- http://rield.com/faq/why-url-shorteners-are-bad : an excellent page discussing all aspects of shortened URLs.
- http://sebastians-pamphlets.com/category/s-url/ : an emotional article including numerous links to other pages criticizing this practice.
Includes phrases such as
-- Twitter decided to break the Web by raping all of its URIs. Twitter’s sloppy URI gangbang became the Web’s biggest and most disgusting clusterfuck in no time.
-- What if the great chief of Libya all of a sudden decides that gazillions of bit.ly-URIs redirecting punters to their desired smut aren’t exactly compatible to the Qur’an? All your bit.ly URIs will be defunct over night.
-- Goo.gl (by Google)... promises stability, security, and speed. Well, at the day it launched, I broke it with recursive chains of redirects, and meanwhile creative folks ... wrote a guide on “hacking goo.gl for fun and profit”
- http://sebastians-pamphlets.com/put-an-end-to-uri-shortening/
- http://www.kottke.org/09/04/url-shorteners-suck
- http://joshua.schachter.org/2009/04/on-url-shorteners.html
- http://tag.us.com/uri-shorteners-suck-ass.htm
- http://techcrunch.com/2009/04/06/are-url-shorteners-a-necessary-evil-or-just-evil/
- http://gregable.com/2009/05/why-do-we-even-need-url-shorteners.html
- http://searchengineland.com/time-to-think-carefully-about-which-country-hosts-your-url-shortener-52579

The fact that you can surmise what the above pages are about is a simple example why shortened URLs should not be used

h1. Software

h2. References

http://rield.com/faq/why-url-shorteners-are-bad :
- the penultimate section describes Free & Open-Source URL Shortening Software.
- the last section has Further Readings, including
Free URL Shortener Comparison Spread Sheet (spreadsheets.google.com)
URL Shorteners: Which Shortening Service Should You Use?
While doing evil, reluctantly: Size, er trust matters
How to cleverly integrate your own URI shortener
- speed and reliability comparison
http://royal.pingdom.com/2010/10/29/is-goo-gl-really-the-fastest-url-shortener-chart/
http://gregable.com/2010/09/googl-url-shortenere.html

h2. Stateful or Stateless
The key question is whether to:
- use a state-full service (i.e. save the redirects),
- or a functional service (i.e. use a 1:1 mapping based on a hash, with no need to store state).

Since we won't let the user select the short URL (a "vanity keyword"), it's better to use a 1:1 mapping

h2. Internal or External

Should we deploy our own service, or use an external service?
I think internal, because:
- see the explanations about security risks and instability
- we'd need to access the external service somehow, and perhaps maintain the mappings
- such service is not very complicated

If external, which one should we select? I'd go with goo.gl

h2. Domain, Resolving
If we decide to go with internal software, then we need to get an actual domain, establish DNS record, and setup a redirector. This is required for short URLs to be resolvable (to work).

Examples of shortening domains include:
- youtu.be
- tcm.ch
- twurl.cc
- tinyurl.com, snurl.com
- is.gd
- goo.gl
- cli.gs
- tr.im
- binged.it
- bit.ly, ow.ly
- fb.me
- su.pr
- twl.tl

These are Top Level Domains (TLD), belonging to some country. Eg bit.ly is Lybia (silly!) and goo.gl is Greenland.

- describe that RS URIs are not resolvable yet, so maybe we should use a fixed short form such as "uri.rs"