When APIs Play Spoilsport?

Romin Irani, January 6th, 2012

ProgrammableWebPublic APIs have given rise to applications that we could not have imagined a few years back. All the stakeholders in the API ecosystem have benefited, right from organizations providing public APIs, to API consumers and the end user that has been given mashups that combine the best of many APIs. However positive this may sound, it is important to look at instances where APIs end up playing spoilsport in their own little way. This post tries to explore some of them.

Consider the case of Private APIs. Our coverage recently on Unofficial APIs highlighted the presence of several APIs that are present but are labelled as private. Developers know that there is an API and itch to use them but are not officially given the API. These give rise to unofficial APIs that are flaky and which could break when the product vendor changes something on the server side, thereby earning APIs a bad name.

Clearly one of the reasons that Private APIs exist is security. A Q&A on Quora asked if there were APIs provided by airlines and credit card companies to extract information like consumer points. The APIs do exist, an example being the Zynga and American Express partnership, but they are kept private due to security reasons or only made available to “trusted partners”.

Next up on the list is API Rate Limits. Every public APIs has its own rate limits. The ideal situation is that of an API that provides reasonable rate limits for developers to try out for free before being bracketed into the paid option. However, there are times when the APIs put rate limits that defeat the very system of developers trying them out. For example, a rate limit of a few thousand calls per month may sound good at first but it completely depends on the kind of API.

If it is some sort of a static lookup with limited data, developers could work around this via clever caching but when the API parameters differ based on user input, a few thousand calls could probably be over in minutes or hours if the mobile application or web mashup that utilizes the API, ever goes viral. A prime example is the Worlfram Alpha API. Developers have been itching to use this API in their applications because of its unique search engine but with a rate limit of 2000 calls per month, it does not seem that anyone would experiment too much with it.

Finally, it is important to consider the number of APIs that have been dropped/discontinued by API vendors. Throughout the year, we have reported various APIs that have been consigned to the API dead-pool. Various Google APIs come to mind over here e.g. Buzz, Wave. When that happens, it forces developers that build their products around them to look for alternatives and also ends up creating an atmosphere where dependence on a single organization to continue providing the API is being seriously reconsidered. It is almost as if you need a plan B or see if it is functionality that you could build out on your own.

Let us know what other reasons you see that concern you regarding APIs? Please share your experiences.

Both comments and pings are currently closed.

One Response to “When APIs Play Spoilsport?”

January 6th, 2012
at 5:47 pm
Comment by: JP

I had an absolutely horrid experience with the education.com API in your directory. I detailed my experience on my website: http://www.jpsoftwaretech.com/the-ups-and-downs-of-apis/

In short, although the API is “free”, it is by no means open. Not only did I have to *telephone* them to explain my intended usage (writing sample code to consume the API in a desktop application), my request was rejected because they literally did not understand anything other than “web-based” API usage. Yes I literally had to call them to explain how I wanted to consume their API. It was humiliating having to answer to a non-tech person who doesn’t even know that you can write VBA code in Excel. Kind of like Dilbert explaining things to PHB.

They insist on receiving a link back to their website (the marketing department must be checking their PageRank every day), so obviously a desktop application wouldn’t be able to do that. They didn’t understand that I write blog posts about the sample code where I would post the link.

All in all a terrible experience and so I would never consider this API semi-private at best.

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.