API proxy vs. API gateway

Recently, someone asked me the question of using API proxy vs. API Gateway.

Well, let’s start with the basic premise. You have your backend services and want to connect to your existing customers or bring in new customers. There are different ways to connect to them— websites, mobile applications, cars, and other IoT devices.

So, you expose an API to integrate with all of them and everything will work just fine, right?

API exposure concerns

Well, not really. There are concerns about security, availability, threats, and monitoring. Making sure that things happening outside your enterprise is not breaking things within your enterprise.

What do you do? Well, you define a proxy. A proxy does a few things for you — it adds transport security, monitoring (SLA, performance), quotas, and access level to different APIs.

So, what we are doing here is taking your existing API and exposing it to consumers via an API proxy.

The keyword here is “existing.” The proxy only works if you already have an API; when you exposed an API from within your organization to the proxy. It added nothing new. That’s not the reality for most businesses.

Most businesses have existing services exposed by one or more applications. Businesses have various applications within their premises that are using these services. These applications can be distributed geographically across different regions. These are services that already existed inside an enterprise.

API proxy vs. API gateway

We need to figure out a way to expose these services as APIs, and that’s where the API gateway comes in. A gateway provides orchestration. This allows you to take the services and stitch them together to build an API.

Mediation is a way to take existing services from various backend sources—like SOAP, JMS, POX (or even modern APIs)—and convert the data into an API for the various consumers. We need to be able to take these SOAP/XML services and transform it into REST/JSON APIs or take a REST/JSON API and transform it to SOAP/XML services.

It shouldn’t matter what format your backend is and in what format you want your API to be.

Read more about what API gateway capabilities and features should you be looking for.

Advanced security

You should be able to go from one format to another. What you shouldn’t have to do is write code — and write a lot of code — to do these kinds of mediations. You need an API gateway that does it seamlessly.

Extending an API gateway adds advanced security and ensures end-to-end security of your payload. It deals with things like authentication, authorization, sophisticated capabilities like Denial-of-Service (DoS) attacks, checking for SQL injection, virus scanning, load balancing, caching, and request shaping.

See also: 12 essential best practices for API security

A gateway provides all of that and it includes a Proxy.

So, the question comes, “isn’t the API Gateway a lot like an ESB?” And “why can’t I just use an ESB to do that?” Generally, the ESB extends your Enterprise application integration platform and sits between your apps and services. It’s essentially an adapter framework to allow you to expose services from your apps.

Can it do mediation? Yes. Can it do Orchestration? Probably.
Messages security? No, not really. Authorization? No, most probably not.

See also API protection: How to create a fortress around your data

Also, an ESB is a very heavyweight piece of technology; it’s costly to do development, make any changes, and you definitely don’t want to deploy this to the DMZ as a security layer.

And that’s the design pattern of your API gateway. It’s designed to exist in your DMZ with API gateway in the inside world (LAN) and the other in the outside world (DMZ)

An API gateway divides the bridge and adds sophistication. Therefore, ESB is part of the application layer and the API gateway lives more externally to that.

Discover a more detailed comparison of API Gateway vs. ESB.

Another question arises, if a gateway can do it all, then do we need an API proxy?

Well, not in most cases. Some may argue that the API proxy may be lighter. Why would you want to do all this heavyweight stuff when all you need is an API proxy?  It may also be said, an API gateway adds weight, could slow things down. But that’s not true.

As my colleague William McKinney recently pointed out, proxies help solve some common visibility and management issues, but they also introduce performance issues and additional point-of-failure risks.

A well-designed API gateway will act as a proxy and only add extra capabilities when required. Which is all driven by configuration and based on their needs.

So back to answering the question of using API proxy vs. API gateway. The answer is you need both and in the same product! It’s why the best approach is through universal API management.

Axway’s Amplify platform uses lightweight agents to automate discovery, capture, and validation of all APIs into one registry where they can be managed, monitored, and governed.

Watch the full demo of Axway’s Amplify Marketplace here.

This approach to API governance reduces risk through a single control point, without impacting existing development centers. It also consolidates all your APIs across diverse platforms, gateways, and repositories and provides common reporting.