Apparently, I’ve gotten the beta for Twitter’s new Retweet feature, so I thought I’d use this moment to rant a little bit about the Twitter Retweet API.

The Retweet API is actually a set of five API functions, and, as per Twitter’s horrible documentation habit, they’re spread across one namespace (“statuses”) but two different classes: “timeline methods” and “status methods.”

I’m not sure how I have the retweet beta UI, but traditional retweets aren’t reformatted automatically for me (the first entry is a retweet). *sigh*

The first thing that annoys me about retweet is that “statuses/retweets” is the first “status method” that doesn’t post information. I mean, just the point you are realizing that maybe the arbitrary classification is a distinction between read-only (GET style) and create/update/delete (POST/PUT/DELETE style), they go put in a read-only method in what they term statuses. Sometimes you have to wonder what they’re thinking (or smoking) at Twitter HQ.

The second thing that annoys me about retweet is it reminds me about the Twitter API in general: take, for instance, statuses/retweet. At first glance, it might seem rather intuitive to just simply have the information you push be just the tweet id. But if you use the website, there is no way to get access to a status only by ID—you need both the ID and the username like in: http://twitter.com/tychay/status/5350619673. Substituting any other name doesn’t return the status (even though it’s public), but statuses/show will show it even if you don’t know the userid of the user.

In other words, the ID didn’t need to be globally unique when using the website and at the time was just an artifact of lazyness and the AUTO_INCREMENT feature in MySQL in the early days of Twitter, but it must be globally unique for the API to work. Therefore, because of the API, the website architecture needs to have a globally unique counter in order to keep track of this—a counter that has messed up a lot of clients out there.

Anyone who has ever built a website knows how short-sighted that is. Anyone who has every built a social network knows how wasteful it is to have ids that are not algorithmically hashable or in some way tied to their partion key.

Not that anything fundamentally wrong with that. It just shows the developers of Twitter made an error and, when given an opportunity to repair the error at an early stage, they cemented the error in the API.

I think of how many headaches could have been avoided had they avoided doing things this way.

Now don’t even get me going about statuses/friends. 😉