API Life Cycle Basics: API Management
API Life Cycle Basics: API Management
When it comes to selecting an API management solution, always to keep the relationship small, modular, and decoupled from other stops along the API lifecycle.
Join the DZone community and get the full member experience.Join For Free
The State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.
The need to manage APIs is one of the older aspects of doing business with web APIs. Beginning around 2006, then maturing, and being baked into the cloud and markets by 2016. Whether it is through a management gateway that proxies existing APIs, natively as part of the gateway that is used to deploy the APIs themselves, or as a connective layer within the code, API management is all about authenticating, metering, logging, analyzing, reporting, and even billing against API consumption. This landscape has significantly shifted lately, with the bottom end of the market becoming more competitive, but luckily there are enough open source and cloud solutions available to get the job done.
Over the last decade, API management providers have collectively defined some common approaches to getting business done using web APIs. While still very technical, API management is all about the business of APIs, and managing the value generated from providing access to data, content, algorithms, and other digital resources using the web. Here are the handful of common aspects of API management, which are being baked into the cloud, and made available across a number of open source solution providers catering to the API space:
- Authentication - Requiring all developers to register, obtain keys, and provide unique identification with API requests they make.
- Service Composition - Allowing for the organizing and breaking down of APIs into meaningful lines of business, and allowing for different times of access to these products.
- Rate Limiting - Limiting and protecting the value of digital resources, only allowing access to those who have been approved.
- Metering - Measuring each call that is made to APIs, and applying service composition, and pricing to all API traffic, quantifying the value of the business being conducted.
- Reporting - Providing analysis and reporting on all activity, enabling API providers to develop awareness, and drill down regarding how resources are being used.
- Invoicing - Accounting for all API traffic and invoicing, charging, and crediting for API consumption, to generate revenue and incentivize the desired behavior among consumers.
APIs use the web, and API management allows companies, organizations, institutions, and government agencies to provide secure access to valuable resources in this environment. API management is about developing an awareness of who has access to resources, understanding how they are using them, and charging or compensating for the value consumed or generated via API access. While much of the conversation in the tech sector is focused on revenue generation at this layer, in reality, it is about understanding value generation and exchange around valuable resources–with revenue generation being one aspect of doing business using APIs on the web.
When it comes to selecting an API management solution my recommendation is to always keep the relationship small, modular, and decoupled from other stops along the API lifecycle, and keeping the business engagement limited as well, allowing you to grow and evolve without lengthy contracts. Every stop along the API lifecycle should reflect the API philosophy, and be kept small, decoupled, and do one thing well. This goes for the technical, as well as the business of doing APIs. Increasingly my storytelling about API management is absent of vendors, and more focused on the nuts and bolts of managing APIs, reflecting the maturing and weaving in of API management into the fabric of the cloud.
Published at DZone with permission of Kin Lane , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.