ESB vs API Gateway – APINIZER

Organizations that embark on a journey of digital transformation or integration with their internal and external stakeholders usually start looking at API Gateway solutions when they start to work intensively with API/Web Services. However, the following question always comes to mind before locating an API Gateway in the architecture.

“If I have an ESB (Enterprise Service Bus), why do I need API Gateway and/or API Management Platform? Most of the functions look the same!”

First of all, let us state that API Gateway and ESB are different solutions and it would be wrong to compare these two platforms with each other. However, as there are some common or very similar features in both solutions, it leads to confusion as to which of the two platforms to use.

API Gateway

An API Gateway receives all API calls from clients and routes them to the backend APIs. Thus, it ensures that all needs such as Authentication, Implementation of Security Policies, Traffic Management Policies, Load Balancing, Cache Management, Message Conversion, Protocol Conversion, Logging, Error Recovery, and similar needs can be met from a central point and with minimum effort.

For more information, you can take a look at this article.

ESB (Enterprise Service Bus)

ESB is an architectural solution in which many systems can be seamlessly integrated. It provides new services by bringing existing applications and resources together.

ESBs implement VETRO (validate, enrich, transform, route/operate) pattern. In other words, it performs message validation, enrichment and transformation, routing between services and orchestration.

Orchestration is the most important difference of ESB from API Gateway. We can roughly summarize this as using the response received from one service to prepare the request to be sent to another service while operating business logic and making enrichment and transformations on the messages. This feature is reflected on the architecture as a strength or weakness depending on how the ESB is positioned.

Another important feature of ESB is that it supports a large number of different protocols, thus enabling integration between almost any application/resource. In addition to SMTP, HTTP, JMS, JDBC, FTP, SFTP, File options, many 3rd party adapters can be given as examples.

Note: ESB brings new and old resources together to create new business processes. API Gateway is a solution for providing and managing access to these services.

So, API Gateway or ESB? What does my organization need?

Those who are looking for an answer usually ask the following questions.

1. I already use an ESB system, why should I use API Gateway?
2. Where will the API Gateway stand in my architecture?
3. ESB and API Gateway do very similar work. Which one should I use?

With the spread of API Gateways, Enterprise Architects have a new architectural solution to solve their integration problems. I’ve often heard API Gateways referred to as “light ESB”. Keeping this in mind, the following questions may help you choose between the two.

Note: The columns in the table indicate which solution would be more appropriate to deal with the matter. However, keep in mind that many API Gateways can do the work seen in the ESB column, or ESB software in the API Gateway column.

TargetESBAPI GatewayProvide a Service to be consumed √Integrate different systems which can not communicate in any way√ Execute business logic and mediation√ Apply security, traffic management policies √Central management layer for backend APIs √Used for internal system integrations, not for external√ Complex API Compositions√ Flexible and lightweight solution √Consumer centric solution √Monetization √

In a nutshell, the architectural structure example below shows us everything clearly. In other words, it will give an idea about how API Gateway and ESB should be positioned in the architecture.