API management is a necessary but boring practice. As developers make use of a mix of public cloud, purchased or open source libraries, and homegrown services, the number of APIs used by developers quickly renders pouring through documentation impractical.
Microservices, usually accessed via RESTFul APIs, cause API calls to rapidly proliferate. Even modest-sized microservices-based systems experience API overload quickly. Agile development can exacerbate the problem of understanding and using APIs. The rapid pace of Agile, especially Scrum, leaves little time for proper documentation of APIs. Documentation often takes a back seat to continuous deployment.
There are a number of other concerns with API management aside from simply documenting APIs. Once APIs are in widespread use, they need to be actively managed to ensure that they haven’t changed and are only accessed securely. Access control of APIs becomes especially important when these are exposed to customer, partners, and the developer community, and monitoring of API performance.
For a developer to use an API properly they must understand the following:
• which API calls exist
• how the API are used and function
• what parameters are available and what data structures the API call expects
• is access to API calls restricted and what controls exist on that access
• how the API calls are authenticated
• error conditions and error codes
• what the expected result sets and data structures are
That’s a lot to remember. Good documentation and reference books exist for major open source and commercial services but not for homegrown and lesser-known APIs.
At the heart of API management is a data problem, more accurately a data management problem. The APIs themselves are a form of data – information that tells a developer how to access a service – and the documentation and controls the metadata. Managing APIs, which are sources of services, is not much different than cataloging, exposing, monitoring, and otherwise managing data sources.
It’s not that surprising then that Informatica has entered the API management market, alongside IBM, Microsoft, MuleSoft, and a host of others. Finding, managing, and securing data sources are Informatica’s bread and butter competency. With developers already using their software to manage data sources, it’s natural for those same customers to want Informatica to help them manage the APIs for the services they create to access and manipulate that data.
As microservices architectures become more prevalent and companies need to expose APIs both internally and to their partners and customers, the need for API management will only grow. Sure, it’s dull but so is changing the oil in your car. It’s not good practice to ignore either.