Survey of URL Shortening Service APIs

URL shortening services map long URLs to shorter URLs usually encoding the path with a sequence of letters and numbers (e.g. "/a2Xf3") and provide a redirect to the original URL when the short form is clicked. The shortened URLs are useful for Twitter tweets since they take up fewer of the 140 characters allotted to each tweet and can be easier to email since many email clients break long URLs into separate lines making them difficult to use (OS X's is particularly bad as there is no way to get it not to corrupt your carefully formatted text/links/code by inserting line breaks willy nilly).

There are dozens of URL shortening services, although many appear to be little more than ad-traps. The proliferation of these off-brand shortening services may be driven by spammers since the shortened URLs allow spammers to post links on sites that blacklist links to domains associated with spam. The more reputable URL shortening services use blacklists like to help prevent the use of their service for spam posting. Some of the services also provide the ability to preview a shortened URL. Not only can a preview help users decide whether or not they want to click through, but a site that receives posted links can use the preview in a programmatic fashion to remove short URLs that point to blacklisted domains.

I took a closer look at the APIs of those services that provide the ability to "preview" a shortened URL in addition to the standard redirection service. Here are some notes. The site with the cleanest API is, an open source URL shortening service hosted on Google's App Engine. Here's an excerpt from the API docs:

Create a New

Create a new and redirect to it (not useful, we know){href}

Create a new and show in HTML format{href}

Create a new and show in JSON format{href}

Create a new and show in XML format{href}

Lookup an

Redirect an to its target HREF{code}

Display an in HTML format{code}.html

Display an in JSON format{code}.json 

Display an in XML format{code}.xml

I really like how simple they've made the API for shortening and previewing in the assortment of data formats. Using the format extension on the shortened URL to get a preview makes sense to me and is easy to remember.

The service at is also nice and simple, although they only provide HTML responses which makes the service far less useful for integrating into other applications.



So previewing with is very easy, just append a trailing '-' to the URL. However, I find the trailing dash less intuitive then's format extension. Another feature of is that you can add additional path elements that are ignored for redirection. So you can do I guess that's somewhat useful, although it obviously makes the URL longer...

The service has a number of additional features. They have user accounts and provide the ability to track usage statistics of your shortened URLs. Their API is well documented and reasonable, but much more complicated as a result of the user/developer accounts and additional features. They host their API docs on Google code, which is an interesting approach for getting a cheap developer community setup. Here's a summary of just the shorten and preview features:



If only provides shorten and preview, I would say that the /shorten and /expand resources are too verbose, but in the context of their API, it makes more sense since they also provide /info and /stats. Like, you can get responses in XML and JSON. They also provide a JSONP callback mechanism.

The winner of the make a simple API hard award goes to snipurl (aka snurl, snipr, Like, snipurl offers user accounts and some additional statistics gathering for shortened URLs. Their API is documented via PHP code examples and requires an HTTP POST.

You can issue a POST request to the program: -- the POST request should send the required information as indicated in blue highlight in the code below. Here is some sample code in PHP, for example, making use of the Curl library: [followed by 49 lines of PHP code]

Scrolling to the bottom of their docs, I noticed that they originally had a simpler API and that they moved to the new API as a result of abuse from unregistered users. Given that their motivation was to make their API harder to use, I think they succeeded.

To end on a positive note, I also found which not only has the best domain name of the bunch, but has a very clean API despite supporting a similar feature set as in terms of accounts and statistics. I'm not sure if it is just a matter of how the API is documented, but it feels a bit cleaner and easier than the API.



I especially like that their API can be used without an API key for low frequency use and testing, but that you can optionally obtain an API key for heavier use and to gain access to additional features.

Technorati Tags: ,

archived on 2009-01-18 in

blog comments powered by Disqus