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, including 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

Exposing an API to the public internet creates three categories of risk that a bare backend cannot defend against on its own: unauthorized access (anyone who finds the URL can call it), uncontrolled load (one badly-written client can take down your backend), and data exfiltration (a misconfigured endpoint can leak a million records before anyone notices). A proxy or gateway sits in front of the backend so these concerns can be addressed once, at the edge, instead of being reimplemented in every backend service.

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

API proxy vs API gateway feature comparison

The capability gap between a proxy and a gateway shows up in the policies they can enforce, the protocols they can speak, and the operational surface they expose to your platform team.

If you need fewer than half of the gateway-only capabilities, a proxy is probably enough. If you need more than half, save yourself the migration and start with a gateway.

The difference between an API proxy and an API gateway is scope. An API proxy is a thin pass-through layer that handles basic security and routing for a single backend API. An API gateway is a full traffic-control surface that handles authentication, authorization, rate limiting, transformation, caching, logging, and developer-portal publishing across many APIs at once. A proxy is something you stand up in front of one service in an afternoon. A gateway is shared infrastructure that the whole organization depends on. Most teams start with a proxy and outgrow it within a year.

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

When to use a proxy versus a gateway

The choice between proxy and gateway usually comes down to three questions, in this order.

• How many APIs are you exposing? One internal API in front of one backend can live behind a proxy. Three or more APIs (especially if any are external) need a gateway to keep policies and developer onboarding consistent.
• Who consumes them? Internal teams that you can email when something changes are fine on a proxy. External developers, partners, or paying customers need the self-service portal, subscription tiers, and documented contracts that only a gateway provides.
• How fast do you need to evolve? Proxies push the cost of every policy change into application code. Gateways let you change rate limits, add new auth flows, or version an API without redeploying the backend, which becomes critical once the team grows past five APIs.

A federated platform like Amplify Fusion is the next step up from a single gateway: it governs multiple gateway runtimes (Axway, AWS, Azure, Apigee, Kong, MuleSoft) from one control plane, so you can keep the proxies and gateways you already have while still getting unified discovery, security, and observability across all of them.

Advanced API security is everything an API gateway does that a proxy cannot. It includes OAuth 2.0 and OpenID Connect for fine-grained user authorization, JSON Web Token validation with signing-key rotation, schema validation against the OpenAPI contract, payload inspection for SQL injection and XML bomb attacks, OWASP API Security Top 10 protections including broken-object-level-authorization checks, and bot detection at the edge. A proxy can enforce TLS and an API key, and nothing else. A gateway can enforce all of the above as configurable policies attached to each API.

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 without writing custom code.

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.