URL Shorteners: Please Resolve

guest post by Adam Hertz

Twitter’s 140 character limit, and the resulting need for URL shorteners, have created a niche opportunity that many companies have sought to exploit.  It makes sense for the URL shorteners: By positioning themselves at this (temporarily) crucial bottleneck, they hope to provide various services to publishers: analytics, link counting, ad-serving, and so on.

This is dandy for the URLs shorteners, and possibly handy for publishers, but it stinks for users, as well as for tool builders trying to help users make sense of social media.  Opaque URLs, which offer no clue what you’ll get when you click on them, are about as inimical to the original spirit of the net as one can imagine.  It’s like a network with proprietary name servers instead of DNS. 

While one might hope that the need for URL shorteners eventually disappears, it seems that they’ll be with us for some time to come.  So in the interim, it sure would be nice if we could level the playing field by providing a consistent interface to resolve shortened URLs.

Right now, it’s a mess out there.  Kevin Marks pointed out that the right way to do this is with http redirects.  Of course he’s correct, but unfortunately, many of the shorteners I’ve looked at completely ignore the redirect semantics of the protocol in their implementations.

Several shortener services (notably snurl.com and bit.ly) have been good citizens and provided simple APIs to resolve URLs.  Unfortunately, bit.ly requires an API key.   Fortunately, snurl doesn’t.  Other services, such as tinyrurl, serve up a small document that you can scrape to find the redirect URL — a hassle, and brittle, but at least it’s workable.  Shorteners bent on serving ads (you know who your are…) are inscrutable; on purpose, one can only assume.

When I first looked at this issue, I assumed someone had already solved the “resolve” problem.  Several colleagues recommended longurl.org.  It certainly has the right motivation, and handles many shorteners.  Unfortunately it doesn’t handle many of the URLs I’m seeing in my day-to-day work.  Ultimately, I think this this sort of approach will fail — as long as the shorteners use whatever patterns they choose, services like longurl will have to chase them around endlessly.

Instead, I’d like to propose that the URL shorteners get together and agree on a common, anonymous API for resolving shortened URLs.  Of all the APIs I’ve looked at, I think snurl.com’s is the simplest, so I’m adapting their approach in my proposal.

Suppose your shortening service is http://MamasLittleBaby.com/ .  You probably hand around URLs that look like this

    http://MamasLittleBaby.com/loves-shortening-bread 

You should support a service called resolve, accessible without authentication or API key, that lets tool vendors do a GET like this

    http://MamasLittleBaby.com/resolve?id=loves-shortening-bread

The result is simply a text string consisting of the resolved URL.  You can get fancy and support other formats like JSON or XML, and serve up extra metadata if you like.

Until all the shorteners get in line, I recommend using longurl.  I’m also making a resolve service available on tweebase.com that supports my proposed resolve API, tries a few hacks I’ve written for various shorteners, then falls back to longurl.  You can access it like this:

    http://tweebase.com/resolve?url=http://MamasLittleBaby.com/loves-shortening-bread

Thanks to Stowe for letting me post this here.