Yesterday I wrote about APIs and mashups, focusing on the publishing of APIs. Today I want to cover some ground from the other direction, building out a business using APIs to access other people’s code (OPC).
Here’s the first reality you should consider, there is no 11th amendment to the Bill of Rights that states your right to APIs shall not be infringed. The cold hard truth about published APIs is that someone is offering them as a courtesy and they can, and sometimes do, decide that it is no longer in their best interest to continue to offer that API. In other words, if you decide to build an application on someone else’s code, be forewarned that you may in fact be on some thin ice.
Here’s a couple of other things you need to think about when building a dependency on another company’s API. The first thing that comes to mind is economics, meaning the API may sit on top of a subscription or licensed service, in which case you will be asking your customers to pay not only for access to your service but to someone else’s as well. In the event that you don’t have a contractual relationship with that entity, well you are basically telling your customer to go sign up for something else and then come back to you.
Speaking of contractual relationships, the absence of one causes all manner of complications. For example, usage restrictions ride on most APIs, and even the most primitive hosted apps can identify spikes in usage from a single calling application when it presents itself. No relationship with a vendor means no path to overcome usage restrictions. Early stage companies can often, and should for that matter, just talk to the API provider to get a pass on usage if they are in the proving stage but at some point you will need to formalize things.
Does the API provide all the functions you require? If not, well you are probably out of luck unless you have a clear and obvious use case scenario that benefits the API provider. They may publish their product roadmap, or in the very least just talk to you about it, but they may not and that means you will have zero visibility upon which to base your own roadmap.
Security is major issue, and will continue to be. Any service that is providing named user accounts and private data spaces will have a basic username/password login and authentication system that will be integrated with their API. Do you want take on the responsibility for storing, and protecting, usernames and passwords? If you don’t then you will be asking your users to provide the credentials in addition to what they may require for your service.
OpenID is a starting point but few services support that mechanism today and it’s unlikely we’ll see a movement accelerate to adopt it. The problem is twofold, the first being no sense of roles associated with OpenID credentials, so while it’s handy for simplifying the login process you still have to deal with the user policies on your own, but in all honesty I would not expect OpenID to solve that issue.
The bigger issue that developers looking to adopt face is that there is no way to authenticate that the person claiming to own the OpenID URI actually does own it. The authentication issue rears it’s ugly head in this scenario: someone gains access to your OpenID URI which then gives them access to every website that supports OpenID.
At any rate, storing usernames and passwords on behalf of your customer is walking a high wire without a net. One breach of security and you are dead meat, no one will ever trust you again. Tread carefully here and make sure that when you are asking your users to trust you with their user credentials that you are doing everything in your power to protect them.
Putting aside user credentials for a moment, you are going to need to make yourself familiar with API keys and how each vendor implements them. This is often pretty straightforward stuff for techies but the licensing agreements that you are agreeing to adhere to in exchange for an API key often have interesting non-technical consequences. Check out the language in Amazon’s Web Services license as an example of this.
Performance is an issue for anyone accessing APIs, if for no other reason than a great many of these mashup applications are NOT asynchronous and that means your overall performance is a function of your most poorly performing service component. Going back to my opening remark, if a service provider is under no obligation to provide the API to begin with, well they certainly don’t have an obligation to provide a high performance service.
Insulate whenever possible your exposure by failing over to a backup service, in the cases where fungibility exists, meaning one service is as good as another. Google Maps not working, failover to Yahoo Maps… and if a service failover is not possible then architect your code so that non-responding service calls are skipped instead of the entire app crashing. BTW, this issue has been coming up more frequently as blogs have begun adopting sidebar widgets and performance has suffered as a result.
ProgrammableWeb lists 441 public APIs and I would bet that in total there is in excess of 1,000 (meaning providers as opposed to individual APIs). Personally, I think building a business on more than a handful at a time is risky business but it is certainly possible if you understand what you are getting into and devote the necessary attention to formalizing your relationship with the provider.
In the case of Google or Salesforce.com that means signing up for their developer and partner programs and building relationships with the individuals in those programs, but for smaller companies like Echosign or Freshbooks you will do yourself a favor by understanding how you benefit them and then building a relationship on the basis of mutual benefit. It’s been my experience that hosted application providers are anxious to work with third party developers to integrate their services in application workflows but that effort is predicted on an assumption that you know what you are doing. If they believe in you they will devote time and energy to accomodating your needs.
Â Tags: API, Mashups