ESB vs. API Gateway: What's the Difference?

What's the difference between ESB and API gateway? In this blog, we compare ESB vs. API gateway and provide guidance on when you should use which one. 

What's the Difference Between ESB and API Gateway?

Enterprise Service Bus (ESB) is a legacy technology for connecting your digital services. An API gateway is a proxy layer for your digital services which manages a variety of features via APIs. An API gateway is often preferred over ESB for its orchestration, integration, and security capabilities. 

Enterprise service buses (ESBs) are legacy tools for achieving enterprise application integration (EAI) tasks. They offered an abstraction layer and allowed for orchestration of various application-to-application transfers. They offered somewhat of a precursor to API gateways and focused on exposing services for reuse. Yet as enterprise needs shift and APIs have become increasingly important, API gateways have proven a more useful tool to achieve orchestration of digital services

ESB vs. API Gateway: Key Differences

An API gateway is better suited to helping you achieve digital transformation, when compared to an ESB. Here are the key differences with ESBs vs. API gateway. 

API Gateway vs. ESB For Service Orchestration

An API gateway is better suited to orchestrating digital services, databases, or applications than ESBs.

Why?

API gateways are simply more flexible and platform-agnostic. Likewise, they align with how critical APIs have become in achieving digital transformation in the modern enterprise. Here are a few key advantages: 

• An API gateway enables API orchestration, which ESBs simply cannot achieve. 
• This creates a higher-level business service that offers meaningful capabilities to consumers. 
• API gateways offer an abstraction layer, via APIs, further enhancing security and mitigating risk. 
• API gateways are purpose-built for a modern organization looking to scale digital transformation using APIs as a central mechanism. 
• API gateways are perfect for microservices architectures, whereas ESBs do not align with microservices. 

And sure, an ESB can be used to orchestrate or aggregate multiple services. But ESBs are not purpose-built to deal with APIs, which is a huge shortcoming. 

API Gateway vs. ESB For Integration

Again, API gateways provide stronger integration capabilities than ESBs. 

Why?

An API gateway aggregates data from different sources with its API integration capabilities.

An obvious example is customer data. In many cases, data about customers is distributed across multiple applications. Think about your banking data. You likely have checking, savings, investment, mortgage, and maybe many other linked accounts. These are most likely not managed by the same backend applications. But your web or mobile application wants to be able to make a single API call to retrieve balance and status information for all these accounts.

You could do this in an ESB, but these capabilities are often more easily and efficiently provided by your API gateway solution. 

ESB Is Not API Native

Most ESBs come from a time where SOAP was dominant. ESBs still use it as a primary communication protocol, often with RESTful capabilities loosely-bolted on.

SOAP still has its place. It is better suited than RESTful approaches for some scenarios.

But an API integration platform needs a deep understanding of:

• Modern API protocols.
• Content types.
• Security standards and approaches.
• Definition languages.

An API gateway delivers on all that — and more. 

ESB Is Prescriptive; API Gateways Are Declarative

An ESB is prescriptive, while an API gateway is declarative.

ESBs tend to require developers to write code to manage even fairly simple mediation tasks. ESBs act in a prescriptive manner, doing exactly what they are instructed to do.

A good API Gateway abstracts interfaces from implementations. It further abstracts policies allowing for a configuration-driven approach to integration. This makes it declarative.

API Gateways > ESB For Network Edge Deployments

API gateways are better than ESB for network edge deployments.

A core function of an API gateway is threat management and prevention. API gateways provide extensive security capabilities that are typically missing from an ESB. This means that an ESB is not suitable for network edge (DMZ) deployment.

Why is this such an issue for internal integration?

Because the definition of internal has changed. In many cases, with enterprise adoption of cloud platforms, the system you’re integrating with is distributed across multiple data centers, business partners, and cloud providers. You need an integration solution that provides the protection you need while still offering the rich integration capabilities you want.

How to Secure Edge APIs and Microservices Mesh

APIs can be major points of vulnerability. That's why it's critical that you learn how to secure edge APIs and the microservices mesh. Get our recent white paper to learn how. 

📕 Get the White Paper

When to Use API Gateway vs. ESB

Use API Gateways For ...

API gateways are preferable to ESB in many ways.  

API gateways are:

• Declarative: Easier to use, less expensive to create integrations.
• More efficient: Higher performance requiring less infrastructure.
• More secure: Suitable for deployment in the DMZ.
• API native: Directly supporting modern applications.

An API gateway is an important part of the API lifecycle — and one of the key API basics.

Don't Use API Gateways For...

There are still some enterprise integration patterns where the API gateway isn’t the right choice.

Although we do recommend you modernize your approach to ditch these old patterns.

Long-Running Transactions

API gateways like to work in a stateless manner offering high-performance and seamless scaling. Long-running transactions consume resources and force a different model in the gateway. It’s not that API gateways can’t handle long-running transactions. It’s more that there are often better approaches.

Human Interaction and Workflow

Where transactions involve human interaction (a special form of long-running transaction) you should really be thinking about breaking the transaction up into multiple different API calls. This is better than trying to implement the workflow in the API Gateway. This is one of the areas where use of ESBs got a bit out of hand in many organizations.

Message Broker

Most API gateways do not include their own messaging system. But a good API gateway can act as an intermediary between the messaging system. And a really good one can even maintain the guaranteed “once and once-only” heuristic of a messaging system.

Where API gateways come into their own is in creating APIs (REST/JSON for example) from an application that listens on and writes to a queue. Good gateways can also do this the other way around, listening on queues themselves and acting appropriately when they see a new message.

All this said, let me reiterate that an API gateway will not typically include its own message broker, and this can be a good thing.

Semantic Mediation

This is another fine line. In the past, we would always say that a gateway should stick to syntactic mediation (think in terms of dealing with the envelope of a message, or the packaging of a parcel). It should not involve itself in semantic mediation (handling the meaning of the content).

A classic example would be transformation of a purchase order form from one company’s format to another. Today this has changed somewhat. Many gateways offer strong content mediation (even if it’s just XMLJSON). Some even offer sophisticated mechanisms for converting documents from one semantic form to another.

Still, be careful about how sophisticated you want to make your document mappings in the gateway as it can quickly become a management challenge.

Go From ESB to API Gateway

An API Gateway provides an excellent integration solution and is often superior to an ESB. 

So, now that you’re armed with all this information, what should you do next?

1. Look at your mainstream integration scenarios.Would they would be better served by an API gateway? 
2. Gather a list of the ways you use integration today and prioritize it.
3. Then work through the list, examining exactly what your current solutions are doing and compare them with the capabilities of a modern API management platform.

At the very least ensure that when you look at new projects, you take advantage of new capabilities rather than continuing to pour money into an already aging and expensive infrastructure.

Try Akana's API Gateway

If you're looking for an API gateway, give Akana a try.

Akana's API gateway protects your data and secures access to APIs. It provides:

• Authentication and authorization.
• Message security.
• Threat protection.
• Analytics and monitoring. 
• Unified API and SOA.
• Flexible deployment.

See for yourself why the Akana API gateway makes it easy to integrate services — and go beyond ESB. 

Click below to find out if you qualify for a free 6-month trial of the Akana API management platform, including the API gateway. 

Try AKANA  ▶️ WATCH A DEMO

👉 Become an Expert

• API Basics
• API Lifecycle
• Microservices and APIs