After my previous article on OAuth 2 scopes, several people contacted me to ask what exactly an API Manager is. In this article, I will aim to provide a clearer idea of why an organization may choose to deploy an API Gateway solution and the associated benefits.
API Gateways
An API Gateway is an infrastructure component deployed by an enterprise at a network perimeter or a security boundary in order to act as a point of policy enforcement and control and to facilitate service integration.
The role of an API Gateway is to act as a central point within an organization through which clients can securely consume APIs.
That short sentence contains a number of important characteristics of an API Gateway so let’s further expand on them one at a time.
Service virtualization
Firstly, the API Gateway virtualizes the services deployed behind it and exposes a fixed contract to the clients on the other side of it, enabling API implementations to be modified and even replaced without impact to the client.
If you think that this sounds a lot like the loose coupling concept behind an Enterprise Service Bus you would be right, except that ESBs are intended to decouple internal infrastructure components such as CRM systems, ERP systems and so on, whereas API Gateways are intended to decouple API consumers from the underlying API implementations.
Whilst ESBs decouple technologies which interact using a range of diverse protocols and messaging standards, API Gateways are (at least conceptually) only focused on services communicating via HTTP and HTTPS.
Additionally, in many cases one of the parties (consumer or producer) is located outside the enterprise perimeter.
API transformation
In addition to virtualizing an API implementation, an API Gateway may also transform an API to make it more suitable for use by the client which will consume it.
A typical example which we often implement for clients is in the context of service modernization where a legacy service, perhaps implemented using SOAP/XML, must be made more accessible to modern REST/JSON clients.
Rather than rebuilding the service, implementing an equivalent REST/JSON solution or creating a wrapper service to perform the conversion, a simple transformation step, often referred to as a mediation policy, is activated on the API Gateway and makes use of capabilities already present within the Gateway solution.
REST API calls passing through the API Gateway are transformed into SOAP calls to the back-end implementation and responses from the back-end are transformed into equivalent REST responses before being forwarded to the client.
Read the full article from SmartWave here.