I’ve been working on a Java framework to develop Twitter services recently and have found the API and Twitter’s reliability to be a real problem.
The strict API limitation of 70 requests per hour (~ 1 API request per minute) is highly restrictive. Especially when you are placed in Twitter-jail for exceeding the limit in a given hour. Forget about making API calls while Twhil is open. That’s the quickest way to bring development to a halt.
That’s frustrating.
What’s surprising is the large number of errors I’m receiving from Twitter on simple requests.
Over the last 7 hours and 30 minutes I have made ~1 request per minute for the replies to the findasong account (findasong is a Twitter service: in an @reply to @findasong include lyrics, a title, artist — whatever you have — it will try to find your song).
Of the 439 requests made during this time, 74 returned an exception. 30 of the 74 erroneous requests were from the API limitation outlined above (indicated by a 400 HTTP response code). So 44 valid requests that went to Twitter returned unfulfilled.
This means, from my sample set:
- 409 request (439 reqs - 30 invalid reqs) should have been successfully processed.
- 30 of those 409 requests were unsuccessful.
- Or … approximately 7.3% of my API requests were unsuccessfully fulfilled.
Imagine 7.3% of your phone calls being dropped. Or 7.3 % of your sent mail being lost. The rate of unsuccessful requests must move toward 0% if Twitter is to cross the chasm, let alone grow.
This gives me an idea how I can further use my framework — I’ll track how Twitter reliability changes overtime. More on that in a bit.
Anyway, great things come from shaky beginnings. Pierre Omidyar recalls similar reliablity issues with eBay:
For most of 1997 I was mainly trying to keep ebay.com site from crashing every day. In re to @ev.
Just voicing my annoyances. Carry on.
![dougw <at] igudo <dot] com dougw [at> igudo [dot> com](http://www.igudo.com/wp-content/uploads/2008/02/dougwemail.png)