The API Billionaires Club is about to welcome Trillionaire members. But how should you deal with it?

The amount of API traffic increases every day. But it’s no longer just the known players such as Google, Amazon, Twitter, Facebook and Salesforce (the API Billionaires Club) that will produce the related massive amount of data. Cisco estimates that by 2020 37 billion smart ‘things’ will be capable to connect with an API. The Internet of Things is here! But how should API-providers handle all these clients?

In this blogpost (the first in a three-part series) we’ll answer the question: What is an API Management package and why should I care?

What's in a name: API Management vs SOA Governance

API Management and SOA Governance are closely correlated and differ largely by way of the profile of the (end) user. Because of the growing number of target devices these last couple of years, as well as the implementation on these devices, these profiles are not always known. API Management is aimed at, next to the classic internal interfaces, external APIs where the consumers are usually unknown. With SOA Governance, this isn’t the case (users are known) and there definitely is a contract in play.

APIs allow enterprise stalwarts to distribute their data in a uniform way, to monetize their apps and for users (human and non-human) to consume (aggregated) data seamlessly. This process is continuously spurred forward by new impulses, called digital experiences, resulting in an evolution towards an Ecosystem Engagement organization. Here, there’s room for rapid (mobile) app development, API creation and security enforcements, while keeping the existing integration foundation and structure.

All of this is facilitated by an API Manager, which typically contains a gateway that arranges the traffic to consumers and secures said traffic based on certain policies that have been determined in an API Lifecycle Management component.

The API Manager is responsible for the design, development, deployment, versioning and retirement of API endpoints. In each of these phases, it’s critical to get consumer feedback on the one hand and reevaluate security on the other. Developers can check the API specifications on a Developer Portal, while API monitoring usually happens in an Analytics component.

Developing for an API Gateway: A programmer's mind shift

Can every developer develop APIs on a gateway? We decided to put that question to the test and asked a number of consultants at AE to experiment with an API gateway for half a day – without any prior knowledge.

The technical audience existed out of a mix of senior and junior profiles, but that seemed to have little impact on the result: it wasn’t very easy for a programmer to get used to opening up policies based on a predefined set of building blocks. These kinds of building blocks can speed up the development process, but they can also provide constraints as they inherently try to abstract more complex functionality. Some API Managers allow code injection in order to tackle these scenarios.

On top of that, every API gateway vendor has its own IDE and functional development language, making even simple things such as an if-then-else structure difficult to find. In other words, there’s a steep initial learning curve. But once you’re past this phase, you’ll get to know the true power of these building blocks: transformation between XML and JSON, protection against SQL Injection, XML attacks, OAuth2 authorization, throttling, … It’s all just one drag and drop away!

To give an example of what a policy looks like in an API gateway, we’ve developed a very simple flow in three popular API Gateways. The flow has to receive an HTTP POST request with 1 letter in the body. In case of the letter A, response A should be returned, in case of the letter B, response B should be returned and in all other cases, response C.

If-then-else CA API Gateway:

In the left part, you’ll see the policy, which is read top to bottom by the gateway. The "At least one assertion must evaluate to true" means we need to make a choice here. Either the first "All assertions must evaluate to true" returns an OK (which means that the request contained the letter A and that the response of A was successful), or the API Gateway moves on to the next “All assertions must evaluate to true". Again, if the request contained the letter B, the response will be B. If neither of the above return a OK, the last step is executed, resulting in response C.

On the right-hand side is a detail of the configuration of the first ‘compare variable’ step.

If-then-else Axway API Gateway:

Another method is to work with binary trees, in which each node of the tree is a Boolean equation. Depending on the result of this equation, we proceed on the green success path or the red failure path. This visualization is much stronger than the previous one.

If-then-else Mulesoft Anypoint Platform:

In the left window, you can see the visual flow/policy that has been developed. On the right-hand side, you can see the features of the “choice” component, where you define when to proceed to the next step. For most scenarios, this representation is the most natural one.

Especially when talking about public APIs, developer adoption is the benchmark that signals whether the chosen API strategy is successful or not. To tackle this, most API managers provide a portal to improve developer adoption. You can look at this as a single point of interaction with your consumers (mostly developers).

A solid portal should contain the following features:

• Self-service capabilities: consumers can register themselves, can register their applications to receive an access code (API key), to consult interactive documentation when they can test-drive your APIs without having to implement anything themselves.
• Differentiation between user types: first and foremost, it has to be possible to give internal developers different rights than partner or third-party developers. Especially when a portal supports monetization, this is a must-have.
• Community features: in general, developers like to discuss best practices, tips & tricks etc. with other developers. That’s why offering an actively monitored forum is a must.

Now you may ask yourself whether a portal is useful for other scenarios. We think this may definitely be the case. In smaller companies with a limited number of developers, having a good and up-to-date developer documentation is extremely useful. In larger companies with multiple development teams and many applications, other features such as API access management (via defined SLAs for example) can protect you against unwanted performance problems etc.

"What gets measured, gets managed." (Peter Drucker) - About the importance of API Analytics

It’s important to understand by whom, how often and how APIs are being used. The large API Manager players offer an out of the box analytics component that monitors and visualizes SLAs, round-trip times, end point and/or consumer usage etc., both short term (identifying discrepancies and interferences, dashboard style) and long term. Based on these historical data predictive, operational and/or commercial analyses can be performed.

APIs are here to stay, and so is API Management

With the continuous growth of API traffic, a robust provider mechanism is necessary. API Managers can abstract a large part of the versioning, security and performance complexity so we can focus on what’s essential: APIs, as simple as possible, but not simpler.

Want to know more about how to properly expose your data to the outside world? Contact us if you are interested in discussing possible API Manager solutions for your business.

Special thanks to Yannick Geerts for his contributions to this post.