What is the difference between API Gateway and ESB?

Question

ESB is traditional middleware used in SOA solutions for routing, message transformation, protocol bridging, among other things. A new category of middleware solutions called API Gateway are now offered by several vendors. These solutions are commonly described as the central point to access the REST and SOAP services offered publicly by an organization. However, API Gateway solutions seem to offer a subset of typical ESB features.

---

So, what are the differences between ESB and API Gateway? When should I use one or the other?

Answer 1

Both could perform mediation and aggregation of services. The major difference is that API gateway exposes a set of services to consume, and be responsible for some of the other functions of a proxy-service; such as rate limiting.

On the other hand, ESB’s give two-way relationships, so both providers and consumers (services) can participate to get a required outcome. In other words, an ESB allows the computation entity to be a service as well as the consumer on-the-fly. API-gateway restricts the a service to have a single behaviour.

There are several major API gateway providers, including:

1. Amazon Web Services (AWS) API Gateway: AWS API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale.
2. Google Cloud Endpoints: Google Cloud Endpoints is a distributed API gateway that makes it easy to develop, deploy, and manage APIs on Google Cloud Platform.
3. Microsoft Azure API Management: Microsoft Azure API Management is a fully managed service that enables developers to publish, secure, and monitor APIs.
4. Kong: Kong is an open-source API gateway and management platform that provides high performance, scalability, and flexibility.

Here are some of the major ESB providers:

1. MuleSoft Anypoint Platform: MuleSoft Anypoint Platform is a unified, hybrid integration platform that provides a range of ESB capabilities such as message routing, transformation, and orchestration.
2. IBM Integration Bus: IBM Integration Bus is a robust ESB solution that provides advanced integration capabilities such as message transformation, content-based routing, and support for a wide range of protocols.
3. Oracle Service Bus: Oracle Service Bus is an ESB that provides advanced features such as service virtualization, protocol bridging, and policy enforcement.
4. TIBCO ActiveMatrix BusinessWorks: TIBCO ActiveMatrix BusinessWorks is an ESB that provides a powerful visual development environment and a range of integration capabilities such as message routing, transformation, and event processing.

Answer 2

API Gateway is a new term for much the same thing.

Background: around 2005, SOA was marketed as the miracle solution to all your (integration) problems and highly oversold, and the key product to buy was an ESB. Things weren't so simple and it all went pear-shaped. The underlying Service Orientation paradigm was and still is sound, but by around 2010 the terms SOA and ESB were burned.

It took another ~10 years to heal, ably assisted by new terms such as API Economy, API Management, API Gateway, as well as, in the case of API Gateway, a crisper set of use cases, namely to expose service functionality to consumers. All functionality is nowadays exposed as services and defined in an API specification - same as preached in the days of SOA, but API Gateway and Service Mesh sound much sexier - and the tools are often much better, nowadays. Additionally, Service Lifecyle and Service Management are also handled by newer, better tools.

Answer 3

One important difference in addition with all above answers:

API Gateway: It is used to consume service (consumer will call/access provider)

ESB: It is used to communicate with service (one service will communicate with other)

Answer 4

It's interesting to read these opinions. Unfortunately, most them reflect that the writer is familiar with API Gateways and unfamiliar with ESBs.

ESB's offer VERTOS, which resolves to...
> validation
> enhancement
> routing
> transformation
> operational monitoring
> security mapping

AWS API Gateway features are a subset of what's offered by, for instance, by Oracle SOA Suite's 12c ESB. In general, the difference is SOA Suite's functionality (VERTOS) is a very well-integrated while API Gateway has split some of this functionality out into separate modules. Consequently, you sometimes have to glue some of these modules together yourself to get to the same level of functionality that comes OOTB with SOA Suite.

Would I choose SOA Suite over API Gateway? Nope. The advantages that AWS API Gateway provides in terms of integration with the whole AWS dev tech stack make it right choice for modern systems.

Answer 5

I agree with other answers, but I would like to add that quite an important distinction is that Gateway shouldn't contain any business logic.

They both do some mediation between services like validation, transformation, and routing, but for example in the case of Gateway validation should only validate the format of the data.

Also, I think ESB could me more about the aggregation of data from multiple services, and it's pretty difficult to do any aggregation without introducing business logic.

Answer 6

An API Gateway is a proxy provided for the client. The Gateway gives the client a consistent interface regardless of any changes within the internal system. It allows the internal system to change without affecting the client. The API Gateway can also provide consistent cross-cutting concerns such as security logging, reporting and API analytics.

An ESB (Enterprise Service Bus) provides a means for service-to-service communication. With this technique, services do not need to communicate with each other, reducing coupling. ESBs often use guaranteed messaging for inter-service communication.

Today, the Service Mesh pattern has become popular for microservices. A Service Mesh implementation can provide both an API Gateway and service-to-service communication, along with load balancing, security and many other features.

There are a lot of variations and implementation details, but this is the high-level difference.

Answer 7

As both API gateways and ESBs are capable of serving service proxies, If one only considers mediation and transformation capabilities of the two tools they may appear identical. The key difference in an API gateway to me lies in the specific purpose it is bred for. An API gateway should be able to act as the entry point to resources fronted by it apart from providing transformation and some routing capabilities. Further, they should be able to delegate access control and throttling aspects to other specialized components, utilizing them it should be able to guarantee desired behavior. As an API gateway would come as a part of an API management solution all of these capabilities will be supported OOTB.

It may be possible to achieve similar behavior for service proxies using an ESB and other external components or software. However, since ESB’s are meant to be used to meet a broader set of integration requirements, and are not specialized for API management use cases achieving them would be a lot harder to do.

Answer 8

An API gateway is something that typically acts as a proxy for your web services and provides interesting value, such as: logging, making SOAP services callable like REST services, debugging help, tracing, etc... Because the API gateway is a sitting between the consumer and your services, it can easily capture traffic and do these sorts of things.

An Enterprise Service Bus (like nServiceBus) is designed to sit on top of a messaging protocol (like RabbitMQ) to give it functionality that does not come with (or functionality that is difficult to implement) the basic messaging or pub-sub, for example: Database stored durable messages, retry logic, listener encapsulation, easier ways to subscribe to messages, and sagas. You can use the messaging protocol without using an ESB but not the other way around. For example, you can use RabbitMQ without using nServiceBus.