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?

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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.

View more solutions