These days the world revolves around publically available APIs (application programming interface). Twitter has an API and Amazon is built on APIs, to name two well-known examples. Any system that wants to allow external applications to interact with it directly will have an API. In this particular article I'll be talking about APIs like the Twitter API - that is, Business to Customer APIs, not Business to Business APIs.
A while back one of the open source projects I work on was approached by a licensing company to chat to them about integrating with their API. We were extremely happy to engage with them on their API as it really adds value to our software, since users have been asking for it. A few days before the scheduled meeting the developers of the project chatted about how the API was likely to be written, and what that would mean for us. Being an open source project we knew that any API that depended on a secret application key would not work, since we would have no way to keep that key hidden in a publicly available source code repository.
The day arrived and as we chatted to the licensing company, I realised that the "worst case scenario" I had described to the team a few days earlier was being confirmed. They had built their API in a very short-sighted way.
Let me explain a little more about how the service they offer works.
They have a web site which allows customers to browse a catalogue, download copyrighted material from the catalogue and, via a yearly fee, pay the license fees for the materials. Many of our project's users make use of this service, which is why we were excited when we heard about the API.
The developers of the licensing company had tried to make the API use established methods of authentication and communication, which I heartily commend, but when it came to the actual implementation they had completely missed the boat. As per our prior discussions, they had decided to go with a secret application key.
This is a short-sighted approach because if one user from one application manages to get hold of that secret, and then decides to make use of it to abuse the system, then the licensing company only has one option, and that is to revoke the application key, leaving all the other users of that application high and dry unable to do what they rightly are allowed to do.
This is an even worse scenario from the application's perspective. The developers of the application now have to rush a "bug fix" version of their application out with a new secret key. Then they have to figure out how to get all of their users to upgrade. If your application requires registration then you can likely contact all your users through your list of registrations, but this is a time-consuming and costly exercise, an even then you have no guarantee that all your users will upgrade. Now you're stuck with a bunch of complaints from users and a tarnished reputation thanks to the negative reviews from affected users.
On top of this, the licensing company decided to charge a yearly fee for applications to use their API. Not only is this fee so expensive that the lower-cost proprietary applications cannot afford it, but it is completely out of the price range of open source projects, which largely depend on the generosity of others. What irks me personally is that the users are already paying for this service, why do the application developers have to incur a cost just so that users can make use of a service that doesn't add a lot of value to the application anyway? Our users still use our application even though we don't have integration with the service through the API.
The reason we were given for charging for the API was that they have ongoing costs maintaining the resources used to run the API. This is a complete red herring. In this particular company's case, their API will never be used as much as their online service (partly due to their own fault), meaning that no matter how many applications sign on to use the API, they will probably never cover the actual costs of running it.
Other systems that offer APIs don't charge for them because they understand that charging for their API hinders the adoption of the API and inhibits the growth of the service. Sites like Twitter are as big as they are these days because they opened up access to their API and allowed applications to use it free of charge, and they did this without having any way to make money from their API. Twitter's API is probably used far more than their web site, and they probably could have supported their web site by charging for their API, but they knew this would be counter to widespread adoption. Twitter's revenue generation issues aside, it cannot be argued that they would not be ubiquitous today were it not for their open API.
So how can these issues be solved? Fairly simply, and without huge changes to the way the licensing company's API currently works.
They are currently using the popular OAuth method for authentication, which they can continue doing, but implement a way for users of their service to generate a secret key rather than rely on an application's secret - log into the web service and generate a key there, perhaps. This gives the service much more granular security, so that when a user abuses the system their access can easily be revoked without affecting the rest of the users of the service. The application also has no need to worry about revoked security tokens and redistribution of new versions of the application. Additionally, by not charging for the API more applications will use the API and more users will use the service provided. This is a real win-win situation for both the licensing company and the applications using the API.