Your API is bad and you should feel bad
A few months ago, TechCrunch reported on a survey undertaken with 100 developers. The topic of the survey was which external APIs were the most difficult to integrate into their projects. The winning by clear majority was Facebook. We’ve all worked with their API before and it can be a real headache. Specifically mentioned by the developers surveyed were the API’s never ending changes and poor documentation.
I’ve had plenty of experience with the Facebook API, specifically the Connect button implementation. It’s flaky at best and – at least under the .NET platform wrapper – has plenty of annoying bugs that you can’t fix. The most annoying was the ‘double refresh’ – returning to a site you had previously connected to did not instantly pick up the stored Facebook cookie. You needed to refresh the page, or visit another link on the site, before the API would accept that you had previously authenticated. It was as if the cookie was not even there.
Twitter and Google Plus are no better. One of our Twitter implementations failed mysteriously when Twitter updated their API overnight and our project that was utilising it could no longer post tweets. Updating to the latest API fixed the problem, but public APIs should not break when new versions are released!
The latest find was a Google +1 integration. Overnight the external JavaScript library begun throwing errors at the same line in the obfuscated, compacted library, that would in turn prohibit ALL further JavaScript requests on the site from loading. This of course annoyed our client, but not as much as it annoyed our developers.
When an API is in beta you accept its flaws. But when an API - built by one of the largest tech companies in the world - has issues, I do wonder how much care is being put into the maintenance of these things. I know I’d never hear the end of it if one of my APIs randomly failed at 3am one day!
