API Gateway
June 26, 2020

What Is an API Gateway?

API Gateways

API gateways are business-critical. But, what is an API gateway? And why do you need to use one?

Read along or jump to the section that interests you most to get answers about API gateways. 

What Is an API Gateway?

An API gateway is a component of API management. An API gateway sits between backend services and a client (requester) to transmit requests and responses. An API gateway receives calls, aggregates services to fulfill them, and returns a result.

Using an API gateway is important to ensure API security

Why Do I Need an API Gateway?

You need an API gateway because it provides a unified entry point across internal APIs. It allows you to control user access. And it enables security measures, like rate limiting, and applies security policies, like OAuth or JWT.

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.

Enterprise API Management Defined

An API gateway is critical for enterprise API management. But what else do you need to form an effective strategy? Find out in this white paper. 

📕 GET THE WHITE PAPER

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.

How an API Gateway Works

Pattern

Most API gateways operate using a proxy pattern. 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 DM. The API endpoint is exposed to the outside world. And the application exposing the service is buried deep inside the customer’s network.

Nonfunctional Capabilities

The gateway will mainly be responsible for adding nonfunctional capabilities, from securing and monitoring the API to routing, transformation, and mediation.

How useful and flexible the gateway is will depend on how it delivers these nonfunctional capabilities for the APIs it exposes. It also depends on how the API gateway is built to satisfy its own nonfunctional and functional requirements.

There are a couple of rules that many of the vendors break:

  • They mix business and nonfunctional requirements together in the same architecture.
  • They describe the complete proxy implementation as policy.

One of the most important principles to follow with an API gateway is the separation of process, binding (style), transport, and policy. As a result, you gain the ability to declaratively define APIs.

Policy Enforcement

In the model below, 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. 

Policy Styles

 

The gateway can define multiple different API styles — REST/XML, REST/JSON, SOAP, etc. — for this abstract interface. It can also expose each of these styles over multiple different transports (http, https, AMQP, JMS) or networks. 

The API gateway can then enforce (and implement) different policies for each transport, style, or message. Plus, it can implement global policies that can be applied to the entire API, all styles, or all messages. There is a ton of flexibility in how and where you instruct the gateway to enforce policy.

How API Gateways Enforce Policies

There are a few key points to highlight here:

  • Ensure flexibility by keeping styles and transports separate from messages and process.
  • Keep policy out of the process to reduce complexity.
  • Establish processes, process steps, and scripts that are architecturally the same.

The use of policy to describe nonfunctional 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. They can associate these assets 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, you might need to comply with a new industry regulation requiring that a certain class of PII be encrypted. With Akana, you’ll really appreciate the ability to use and share a single policy across all the APIs, messages, styles, and transports to 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. 

It's easy to:

  1. Take an internal SOAP service on a transport like JMS using complex WS-Security policies.
  2. 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.

API gateways are an important part of the API lifecycle.

👉 Become an Expert

Explore:

What's the Best API Gateway?

The best API gateway to protect your data integrity and deploy across multiple clouds is Akana. The Akana API gateway delivers power, resilience, and flexibility. So, you can accelerate time-to-market without sacrificing security. 

That's why the Akana API gateway is the gateway of choice for one Fortune 500 company (among many others). Read the case study >>

With Akana, you get:

  • Fast authentication and authorization.
  • Compliant message security.
  • Mediation and transformation.
  • Automated analytics and monitoring. 

Experience the Akana API Gateway

See for yourself why the Akana API gateway is the best option for your business. Try our API management platform for free with a 30-day trial.

TRY AKANA FOR FREE  ▶️ WATCH A DEMO

Send Feedback