This is a contributed piece written in full by Olaf van Gorp, technical sales (EMEA) and solutions consultant, Akana at Perforce Software.
From this point, van Gorp writes in full as follows…
Sure, APIs are technically code running somewhere that allows you to interact with a system somewhere else, but with the API economy evolving and (potential) API consumers becoming ever more significant, a successful API strategy should go beyond the technical interface.
APIs need to be easy to find and easy to use (for instance, supported by the right documentation, which is often not the case).
Next to functionality, aspects to consider include SLAs (what response time can I expect, what level of availability is guaranteed?) and so on.
API waiter theory
The waiter analogy is important — i,e, that APIs are the messenger — is a valid starting point, but what is essential is the ease-of-use of those APIs. So, the client needs to know how to find the waiter, or which waiter to ask for (or even to know that they need to ask the waiter), how to address them (do I need a menu? how many courses are there?), what input to give (any conditions that may apply – for example, can the food be expected to be returned within a given time?).
The point here is that APIs need to be thought of as much more than just code or interfaces: they are products that are fundamental to the smooth-running of all kinds of organisations, whether for external usage, or to support smooth-running of business applications internally (it’s not just external APIs that need to be productised).
For the API creator, there are other aspects to consider: how do they monitor an API’s consumption if it’s being deployed worldwide?
What about security? Testing the ‘product’ aspects?
Also, API productisation needs to focus on making the technical API interface readily consumable by designated consumers. In other words, API productisation is essential for any successful API programme. One of the challenges with APIs is predicting what consumers will require.
Again, the productisation approach helps, by reusing APIs as building blocks to fit different use cases, mainly implemented in the API interaction layer.
We can also think about best practice elements to consider, such as: understanding consumers’ use case scenarios, describing them properly in the chosen API marketplaces/repositories, wrapping the right documentation around APIs, with instructions and use cases, having a security-first mentality when developing APIs, and implementation of testing that is more ‘product’ oriented.
Perforce’s Akana is a cloud-agnostic (in fact it can be deployed anywhere), API management product, containing an enterprise-grade API gateway component along with a highly secure Developer Portal, supporting enterprise-wide API management across any network zone.
Olaf’s been part of the Akana team since 2014 (Akana became part of Perforce following the Rogue Wave acquisition a few years ago).