Realizing the vision of an API-driven organization with WSO2 API Manager
By Nadeesha Gamage
- 13 Sep, 2013
As organizations around the world leverage IT infrastructure to improve their business operations, it brings the need to expose these systems to multiple stakeholders within the organization to improve quality of service as well as efficiency. The solution to this is to expose these IT capabilities within the organization as APIs. A developer community within or outside the organization can use these APIs to develop applications that can access the backed IT systems of the organization. However, exposing internal IT capabilities of the organization as APIs has its own problems. This article explores how WSO2 API Manager can help an organization to achieve the vision of an API-driven organization by overcoming its inherent pitfalls.
WSO2 API Manager
1.0.0 or above
Table of contents
1. What is an API
2. Why APIs are important to an organization
3. What are the drawbacks
4. What is the solution
5. Why WSO2 API Manager
What is an API?
API is an acronym for Application Program Interface and defines the way in which a software component of a system can be accessed by another user or an application.
Why APIs are important to an organization
A typical organization would consist of hundreds of IT systems that make up the complex IT infrastructure of the organization. These systems would be span across the organization's boundaries with each system, typically confined to one or a few departments within the organization. Access to such systems would be restricted only to the users within that particular department. However, these systems would be useful to other departments within the organization, which would require access to these systems. Similarly, an organization would require for some of these IT systems to be exposed to the outside partners of the organization that can use the data to provide a better service to the organization and its customers. This can be achieved by an organization by exposing its systems as APIs. APIs can be used by a developer community internal or external to the organization to develop an application using these APIs. Application developers can develop applications from these APIs that would allow employees, partners, and customers of the organization to use these services, which previously would not be possible. For example, a supermarket would want to expose their inventory control system to its suppliers. This would allow the supplier to write an application based on the API to better manage their own production schedules to reduce stock outages. The supermarket would benefit from this by being able to maintain a low buffer stock and reducing its stock holding cost. The supermarket’s internal inventory control system would have the capability of identifying the stock level for a given product. This internal capability has to be shared with the product supplier. This can be achieved by allowing the supplier to access the stock level within the inventory control system of the supermarket via an API. An application developer at the supplier’s end can use this API to develop an application that would provide a real-time stock level in the supermarket to plan production for the next batch of products.
As explained in the supermarket example, an organization, irrespective of its size, can use APIs to expose its system capabilities as APIs and allow developers to write applications that can use these APIs to achieve a given task.
What are the drawbacks?
Even though exposing backend services as APIs offers significant advantages to an organization, it also has its own inherent drawbacks. Exposing an internal system as an API would make the system vulnerable to attacks. The API would allow direct access to the system and expose the internal network infrastructure of the organization. This may be more apparent in a case where internal APIs have to be exposed to external users outside of the organization. Similarly, controlling access of APIs would also be a problem for an organization once APIs are exposed to different organizational stakeholders. An organization would not be able to control ‘who can access’ the API and ‘at what frequency’. In the case of the previous supermarket example, the supplier application would want a near real-time stock update that would provide a very accurate stock level of the supermarket. However, this would strain the inventory control system of the supermarket, which would have to service a large number of requests coming in from the suppliers and may even cause disruptions to the core activities of the system.
As the scale of the organization’s API library increases with a larger developer community, it creates problems in communicating and managing the available APIs. Developers would want to be able to search for available APIs from the API library, which would be most useful to them. This will not be possible if APIs are not managed.
When the organization exposes its services as APIs, it needs to manage the updates of these exposed services. For example, in an instance where the organization would want to change the API definition of an exposed API, it will have an impact on the existing applications that have subscribed to the API. If the API definition is changed without changing the applications that embed these APIs it would cause the application to fail. Hence, the organization would have to stick with a fixed API definition throughout the production period, and if the API definition is changed, it would have to be done by creating a new API and will have to be communicated to each individual application developer who uses that API.
An organization that exposes the APIs would want to monitor the performance of the API to understand to what extent the APIs are used by its subscribers. It would allow an organization to understand trends in API invocations and improve its services based on the API usage. However, it would be not possible track and collect statistics on API invocations as APIs are exposed in an ad hoc manner.
All the above mentioned limitations are caused due to the lack of manageability of APIs that makes it very difficult for the organization to have a way of controlling API access in a scalable manner.
What is the solution?
In order to address the above-mentioned problems, an organization would have to introduce an API management layer that would be able to manage all exposed APIs within an organization. The APIs exposed can be made available through a web portal whereby application developers who are authorized to access the APIs can explore and subscribe to the required APIs to develop applications. API invocations can be secured to ensure only authorized applications are allowed to access the APIs through the API management layer. An API management layer would act as a reverse proxy and would only expose the API end-point at the API management layer; hence, the internal network infrastructure is not exposed to external applications.
API access can be throttled so that access to the services can be controlled to ensure that back-end services are not overused by applications via APIs. Similarly, an API management layer can manage the API lifecycle of the exposed APIs. Managing the API lifecycle would eventually allow the organization to manage the APIs better to provide high availability of APIs. API lifecycle management can be used to assist API versioning where the current API definition can be changed by creating a new API version without impacting the current API users.
Implementing an API management layer would create a central point of access to all APIs that would allow monitoring and statistic gathering possible to provide vital API invocation information to an organization.
WSO2 API Manager can provide a complete solution to publish, secure, manage, and monitor APIs of an organization. It will provide a properly governed API infrastructure to an organization that can be exposed to an internal or external developer community.
Why WSO2 API Manager?
WSO2 API Manager is an open-source API Management solution that provides a complete solution to publish, secure, manage, and monitor APIs that are available to an organization. The API Manager provides a scalable way for the organization to expose its API library to a wider developer community. It provides the ability for APIs to be published to an API Store that can be accessed by the application developers. Access to the store can be controlled by authenticating users against an Active Directory, LDAP users store, a database based user store, or the internal user store provided by WSO2 API Manager. API invocations made by applications can also be authenticated against a similar user store. Application and user identity is managed through OAuth 2.0 security tokens. An application should have a valid OAuth2.0 token to access the backend API; hence, backend services are secured from unauthorized access. Auth 2.0 token generation, management and validation would be handled within WSO2 API Manager. WSO2 API Manager also provides a RESTful interface for token management that can be used by application developers to generate tokens required for their applications.
WSO2 API Manager contains four different components; API Publisher, API Store, API Gateway, and Key Management Server. These four components are bundled together as one product in the API Manager distribution. However, it is also possible to deploy each of these components separately to achieve a highly scalable deployment. The API gateway component of WSO2 API Manager is an instance of WSO2 Enterprise Service Bus (WSO2 ESB), which allows WSO2 API Manager to perform functionalities available within WSO2 ESB. These include message transformation, enrichment, routing, and protocol bridging. For instance, a REST API can be exposed as a SOAP service to an application through the message transformation capabilities of WSO2 API Manager.
WSO2 API Manager provides a comprehensive API governance strategy whereby each API would go through a pre-defined API lifecycle. Each API can be moved through the stages of the life cycle to minimize any negative impact on the API users. WSO2 API Manager also supports API versioning. Hence, a new version of the API can be created whenever the API definition needs to be changed. This will not have any impact on the existing API and its subscribers. Once the new version of the API is ready for production, the existing version can be deprecated and phased out of production.
WSO2 API Manager also supports multi-tenancy that allows API Manager to have multi-tenanted API stores available to its application developers. This would be particularly useful to an organization where it needs to have multiple API stores for each set of users. Each tenanted user store will have its own set of APIs that can be accessed by application developers allocated to that particular tenant.
In addition, WSO2 API Manager provides capabilities to collect API invocation statistics. These statistics can then be published to WSO2 Business Activity Monitor or to Google Analytics for data analysis to generate reports on the API invocations.
WSO2 API Manager is based on an award winning, component-based carbon middleware platform of WSO2.
With organizations increasingly opting to expose its services as APIs for application developers, it is important to focus on how to manage these APIs. To this end, WSO2 API Manager provides an ideal solution in managing these APIs in a scalable and efficient manner.