Kin Lane, the API Evangelist, has produced a list of the Ten API Commandments for Providers.
It's a very good list, including privacy, security, and documentation. I encourage everyone to read it and comment.
What about the corresponding list for API Consumers? Although I don't want to compare myself to a biblical figure (or indeed to Kin Lane :) ), here is my crack at a list of API commandments for consumers:
1. Protect your API Keys.
API Keys are often issued to developers through an API Portal
to use in their apps. These API Key allow developers to access apps. Sometimes the keys are used in conjunction with OAuth, or sometimes they are used in a pure API Key based authentication scheme. It is natural for developers to use Github as a repository for their code. But, what if the API Key is baked into the code of your API consumer app? Ross Penham recently wrote about the disturbing amount of API Keys which he found in Github
. A good solution is to use an API Gateway to manage the API keys
, separately from the API consumer application itself.
2. Understand how APIs affect your client app's performance.
If an API call is slow, then your app is slow. Users may then understandably complain. What if the problem is not your app itself, but an API it's consuming? How you can isolate the problem, so that you can see how a slow API is affecting your users? The answer is to have Root-Cause Analysis in place for your APIs. Here is an example of how you can track the response times of the SalesForce.com API
. Here is another example, this time from the mobile telco 3 in the UK.
In this way, you can point your finger at the problem, and apply root-cause analysis.
4. Think about the data.
When calling an API, it's natural to think about the security of the API call itself. Commandment #1 above is about securing the keys used for the API call. But what about the data being sent to the API? In many cases, you can think of an API as a conduit for data. If this data contains anything private, in terms of what is called PII (Personally Identifiable Information), then it must be encrypted, redacted, tokenized, or removed by an API Gateway
5. Plan beyond asynchronous request response - think about WebSockets, AMQP, MQTT, and CoAP.
HTML WebSockets are an exciting technology which we're seeing customers begin to leverage for their API consumption. WebSockets brings some great capabilities, such as full-duplex communication with the capability for APIs to "push" data to the client. But, it also brings security questions, and a veritable alphabet soup of new protocols beyond HTTP. The good news is that companies like Axway are thinking about the interplay and security of these new protocols. For more reading, I recommend checking out December's AMQP WebSocket Binding (WSB) which was drafted with help from my Axway colleague Dale Moburg
6. Loose Coupling.
Yes, "Loose Coupling" is something that isn't new - in fact it is a dictum of SOA-based integration from ten years ago. However, it is just as relevant now. Don't hard-code your API consumer to a particular version of an API. In fact, by putting an API Gateway
in place, you don't even have to hard-code your API to a particular API (e.g. you can switch between different storage services).
8. Look beyond the Mobile or Web client to the Internet of Things.
Until recently, API clients were assumed to usually be mobile devices. In fact, if you see a diagram on a Powerpoint slide of an API being called, it is usually a mobile app which is doing the calling. Now, we're moving on to the "Internet of Things" (IoT). IoT raises interesting requirements for API Consumers. For example, how can a low-powered device (like a lightbulb) perform the requisite processing required to access an API? What about devices which have intermittent Internet connections (e.g. a Connected Car, which may not always be online). At Axway, we've produced a Webinar and associated White Paper with Gunnar Peterson on the new security requirements when accessing APIs in the Internet of Things.
I encourage folks to check this out.
9. Take a broad view of APIs: XML is unfashionable but still exists.
If you look at some APIs used in business-to-business contexts, you often see the more heavyweight XML-based standards like AS2 and ebXML used. For example, later this week we are running a Webinar about accessing Australian Government "Superfund" services
, and this uses an API which heavily XML-based. You won't find "I ♡
AS2" or "I ♡
ebXML" written on a sticker on the back of a MacBook Pro anytime soon, but if you are writing API Consumer apps which will access Enterprise APIs, you ignore these older types of APIs at your peril.
10. Spread the word.
Here I echo Kin's commandment to spread the word - to evangelize
- your API exploits. In the case of API Consumers, this is just as important as API Providers. On our API Workshop
tours, we've had API practitioners speaking about how they are using APIs. Watch this space for news on our upcoming API Workshops, and feel free to get in touch if you have any great API Consumer stories, or tips to add to these Ten Commandments :)