Within an API management platform,
An API gateway sits between the backend services and a client (requester), transmitting requests and responses. An API gateway receives calls, aggregates services to fulfill them, and returns a result.
There are quite a few products on the market that are billed as API gateways; many offer similar capabilities, often delivered in markedly different ways. Let’s take a look at how an API gateway should be built, and why you should care about the way your API gateway works.
Most API gateways operate using a proxy pattern, where the gateway listens for incoming API requests that it routes to a service exposed by an application. This is often deployed in a customer’s DMZ with the API endpoint exposed to the outside world, and the application exposing the service buried deep inside the customer’s network. The gateway will mainly be responsible for adding non-functional capabilities, ranging from securing and monitoring the API, through routing, transformation, mediation, and much more. How useful and flexible the gateway is will depend on how it delivers these non-functional capabilities for the APIs it exposes, and how it is built to satisfy its own non-functional and functional requirements.
There are a couple of rules that many of the vendors break:
One of the most important principles to follow with an API gateway is the separation of process, binding (style), transport, and policy; and the resulting ability to declaratively define APIs.
Related >> What Are APIs?
In this model, the gateway defines the API as an abstract interface implemented by a process with input and output messages. In many cases the process will be nothing more than a simple invocation of a service exposed by the application mentioned above. The gateway can define multiple different API styles (REST/XML, REST/JSON, SOAP, etc) for this abstract interface, and can expose each of these styles over multiple different transports (http, https, AMQP, JMS) or networks. It can then enforce (and implement) different policies for each transport, style or message, as well as the global policies that can be applied to the entire API, or all styles, or all messages, etc. There is a ton of flexibility in how and where you instruct the gateway to enforce policy.
There are a few key points to highlight here:
The use of policy to describe non-functional requirements is a big differentiator between the Akana API gateway and many others. By ensuring the separation of policy from process, message, style, and transport, we allow our customers to define policies as reusable business assets that they can associate with multiple different APIs and services, rather than monolithic objects that have to be rewritten for each service anytime a business requirement changes. For example if you have to comply with a new industry regulation requiring that a certain class of PII be encrypted, you’ll really appreciate the ability to use and share a single policy across all the APIs, messages, styles, and transports that expose this data.
One of the real beauties of this architecture is that the separation of policy, process, message, style, and transport applies to the downstream services as well as the API. This means that it’s incredibly easy to take an internal SOAP service on a transport like JMS using complex WS-Security policies and expose it as a RESTful API with JSON content secured by OAuth over https, and you can do this without writing a single line of code, or suffering through a complex integration process. Furthermore, if something changes on the internal service, it’s a simple matter of telling the gateway what changed and letting it do the rest. Or if you need to add another transport or style (or both) to your API, the gateway will do it for you with a couple of clicks of a mouse.
Try our API management platform for free with a 30-day trial.