It is abundantly clear that we are living in a world of APIs when my most IT illiterate friend mentions that his company is “looking at expanding into the cloud with an API program”. To his credit, he freely admitted that he didn’t have a clue what it meant, but was happy to reap the benefits of the positive effect it had on his sales!
More and more business leaders are realizing the importance of the API culture and how they can take advantage of it. But, due to the demands on traditional IT departments, they are leaning toward setting up their own departmental API programs. So, the question remains, how as IT practitioners can we best assist the line of business without stifling ambitions?
In my opinion there are two key parts to the story. First, how to provide them with the APIs they need and secondly, how can we best distribute those APIs to their business partners.
As IT professionals, we have to be aware of things that the business doesn’t worry about. If you ask the business whether they want security, 24×7 availability, and guaranteed SLA’s, they often respond with a blank look and uncertain nod. Of course they want all of this, but they don’t understand the impact that it has on IT.
To some extent, it does depend on the industry that you are working in. In financial services, everyone is more aware of security aspects as their day-to-day lives are driven by complex regulation and oversight, but this is not always the case in other industries. For those who are aware of security requirements, do they know the difference between a Diffie–Hellman key exchange and a PSK? Do they need to?
We’ve been creating APIs since computers were first invented, but recently, we’ve changed the way that we will think about APIs forever. APIs are no longer just a way to access some part of an application on demand. APIs are now the primary purpose of our applications, the primary way that we interact both within the application space and externally. Not only that, but we have fundamentally changed the way we build applications, from large, slow moving leviathans of source code, to small, focused business functions that are agile but highly interdependent apps that can be deployed automatically using the latest DevOps techniques.
This leads us onto a new set of problems—how do we control and interact with the APIs we have built in a way that doesn’t lead to an integration spaghetti nightmare?
It helps to look at your APIs and attempt to classify them. Personally, I like to think of things in sets.
At the center, we have core APIs that tend to be deeply technical (maybe even more infrastructure-related) that are used by the application to provide specific business functionality. Then there are APIs that are the core of the application and are only really relevant to the application that you are building (not destined for sharing). Around these we have the application APIs that expose the business functionality to the application itself and to other applications. The last set is APIs that are built to expose functionality or data as an experience layer, often direct to a web app or mobile app.
Each of these layers moves at different speeds, with the core moving slowly and the experience layer moving the quickest. The outer layer may even consist of throwaway code for a short term event, like a retail promotion.
We then have to consider APIs that create functionality from your APIs. These break down into orchestration APIs, that “glue” together APIs into a bigger functional component that are frequently used together, and mediation APIs that provide a technology bridge (for example SOAP/XML to JSON).
Once you understand the purpose of the APIs you create and who you expect to be the users of those APIs, you can look at how you want to manage them. For APIs that are “core”, is there any point in having anything between the API and the consumer? For an experience API, there will be very good reasons why you’d want to introduce some form of management or gateway function. Then you must address additional challenges, such as determining and measuring the metrics you need to track, or how to authenticate users and ensure your APIs are only exposed to the right people.
So we’ve created the best APIs that we can that solve every need of the business. We’ve used the best techniques that we can, they are agile, robust, and highly performant. Now what? How do we expose the APIs to the right consumers, in a way that they can find them and know how to use them?
In the past, we might have deployed a webservice on J2EE app servers in our own data center, configured the firewall to give access, and told the website development team the URL of the service. But the world has changed—we need to provide access to more than just one user, we have many more security threats to manage, and we have many more API endpoints to manage, and probably across disparate platforms too.
Let’s consider the security angle first. Let’s just assume that all of your APIs are hosted internally in your datacenter. How do you secure the front door? Were it your home, you would probably have a high security lock, steel or composite material door construction, and laminated glass. For your datacenter, your first line of defence is the network hardware infrastructure. You will have network appliances that provide firewalls, routing and load balancing, DOS attack protection, and web security/firewall capabilities. So why do most API gateway products push very heavily security-based features?
I was asked recently why we don’t have DOS or DDOS features in our products, to which I used the home analogy—is it better to lock the front door or chain your TV to the wall? You consider your API gateway as part of the application infrastructure, not as part of the network layer. That’s not to say it should be without security, of course. It must handle authentication and authorization and it must be able to handle data encryption. But much more beyond that should be the realm of the network hardware infrastructure. The API gateway’s main responsibility is to enforce the policies that you configure, to control what APIs are available, who can access them, and how much can they do with them.
The difference between a pure gateway and an API management solution starts here. For API management, you need the ability to define the APIs that you need to expose and define their characteristics and capabilities. But now, you need to go further and define how you want to group or package your APIs together and then define controls around SLAs to determine how much the APIs can be used. Add to this features like reporting and monitoring to determine how the APIs are being used and by who. Then add in capabilities that provide developers with a fully customizable portal with self service registration, API key management, and online interactive documentation and you are starting to understand that API management is so much more than just a simple gateway.
TIBCO can help your journey to API nirvana! API creation and integration capabilities:
API management and gateway capabilities:
—As a SaaS solution with TIBCO Mashery
—On premise with TIBCO Mashery Local
—As a Hybrid configuration of Mashery SaaS and Local