Why should you think of API management as a platform? Because it’s becoming one of the most prodigious and important aspects of how Enterprises of all sizes participate in the digital economy.Keeping in line with the standard platform technology definition, an API management platform supports the deployment of Enterprise APIs without the introduction and expense of a new process or technology. A platform allows the management of APIs as a first class citizen for the Enterprise.
To date, many of the discussions around API management from vendors and analysts alike have been very technology or implementation focused. This is understandable as APIs tend to appeal to a technical audience. The details are great but sometimes it is worthwhile to step back and look at general capabilities.
If we take the wider view, what sort of capabilities or functional modules should an API Management platform have?
Gartner’s Eric Knipp released new research last week that begins to define API management as a complete platform. The research is entitled Run and Evolve a Great Web API with API Management Capabilities. Not everyone will have a Gartner subscription, but I think this research will be one of the most important for Enterprises looking to deploy API management due to the breadth of material it covers.
In this research note, Eric is one of the first analysts to describe a comprehensive set of capabilities for API Management.
API Management Platform Capabilities
He breaks the topic into four categories which he calls (i) enable developers, (ii) manage the API life cycle, (iii) communicate securely, reliably, and flexibly, and (iv) measure improve business value.
Enabling developers includes all aspects of managing API metadata, the API catalog, community management, and also includes interesting capabilities such as developer API customization which is an advanced concept that really puts the developer in control of the API. Here the developer can morph the interface to their liking, allowing the consumer to effectively participate in the interface design. It really puts the developer at the center of how data is accessed. Also, this category expands the discussion to include the notion of SDKs and sample code that developers can directly incorporate, moving one step beyond just providing interfaces definitions.
Managing the API Life cycle includes how APIs are published, how versioning is handled as well as changes and issue tracking. For example, an API management platform needs to have CRM capabilities and ticket tracking, truly treating the developers as customers.
Communicate Securely, Reliably, and Flexibly includes all aspects of surfacing APIs from legacy systems, scaling traffic, handling authentication, SLAs, building service orchestrations, and providing threat defense and data privacy. This is the largest category in terms of the sheer number of capabilities and approximates the “runtime”or “traffic’ portions of moving data in and out of interfaces.
Measure and Improve Business Value includes all the capabilities needed to relate APIs to the business as well as measuring uptime, activity, user auditing, contracts and terms of service, and SLA monitoring. This generic set of capabilities answers the questions: Is my API providing value? Is it up and running? How are business relationships maintained?
One of the merits of this article is that it does a great job of outlining precise requirements without diving into specific implementation choices. As with most things that involve software and technology, implementations can have different physical instantiations but still support a consistent set of common capabilities. Talking in capabilities allows decision makers to stay out of technology “rat holes” that can color and bias business decisions.
Long Live APIs
This research note advances the discussion around API management by widening its scope and purpose, moving it from a technology discussion to a capability and platform discussion. Early in the article Eric widens the definition of APIs.
He explicitly covers messaging APIs, SOAP APIs and custom APIs in addition to RESTful APIs. I think this move is absolutely correct. Not only does it more closely approach the original definition of the term, but it matches well with the idea of subsuming the older SOA terminology to militate under a new banner of APIs, similar to a previously article I wrote on the subject, Long Live API Management.
We are only killing the name, not the act of service enablement. Eric’s article seems to represent APIs as big concept, including the full suite of programmatic access whether realized as REST, JSON, XMLSOAP, XML-RPC, Messsage-Oriented-Middleware (MOM), FTP and file protocols, as well as (correctly) broadening the definition to include software development kits and sample code. One can even go as far as to say any programmatic interface is an API – and voila, APIs are regaining their original definition as a true application programming interface. The lesson here is to ditch the jargon and apply what works for the Enterprise.
Eric also makes some statements around APIs a universal tunnel to the Enterprise and correctly describes them as follows: “As a programmatic channel into your enterprise, it is critical that you identify and address any attacks or misuse of your API”.
This critical point highlights the importance of APIs moving forward, if businesses like Expedia are doing 80% of their revenue through APIs, it’s APIs that are the front door to your Enterprise, and by implication, apps that send and receive data over this channel, – not necessarily the website.
Attackers always look for the weakest link, and APIs are largely wide-open at this point. Many of the existing 30,000+ APIs in the wild have been optimized for rapid adoption and bolstering a developer ecosystem, not for protecting Enterprise assets.
This is why APIs need rock-solid, bulletproof API management for increased protection.
APIs and Data Protection
Eric also mentions encryption under the data privacy category and talks about both transport level security and message level security. To expand the discussion here we can also add things like JSON message level security, format preserving encryption and even the “ancient” WS-Security/XML Security protection mechanisms here. I was also excited to see the inclusion of data masking. Eric describes this as two-way, which I think is the correct approach though my terminology would be different as we use the term tokenization here, but the concept is the same. The distinctions we use in our product line include redaction (for one-way removal of sensitive information) and tokenization, to indicate a reversible mechanism for replacing plaintext with a surrogate.
I can’t reproduce Eric’s entire article here, but it’s definitely worth a read and matches what we are hearing from Enterprises today – it’s about understanding and supporting the breadth of capabilities.
If you’d like more information on Intel’s API Management products, please visit our website.