Image Blog Gateway Integration Server
May 10, 2018

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

API Gateways
Integration

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?

ESB is an approach to connecting your services. An API gateway is something that acts as a proxy for your services. An API gateway is often preferred for its orchestration, integration, and security capabilities. 

ESB vs. API Gateway: Key Differences

An API gateway is better than ESB in most areas. Here are the key differences in ESB vs. API gateway. 

API Gateway > ESB For Service Orchestration

An API gateway is better suited to orchestrating services than ESB.

An API gateway enables API orchestration, which is faster and easier than using ESB. This creates a higher-level business service that offers meaningful capabilities to consumers. 

Sure, ESB can be used to orchestrate or aggregate multiple services together. But it pales in comparison to an API gateway. 

API Gateway > ESB For Integration

An API gateway provides stronger integration capabilities than ESB. 

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.

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 sign up for a free 30-day trial of the Akana API management platform, including the API gateway. 

Try AKANA  ▶️ WATCH A DEMO