API Management and ESB: What's the relationship?

In my previous blog I discussed the various elements that go into making up API Management.
In there I hinted that there is a strong relationship between API-Management and Enterprise Service Bus (ESB).  In this blog I'll explain what that relationship is...

The diagram below shows the very high-level view of API-Management. The API-gateway is exposing your back-end services to the world (whether that 'world' be the internet; other businesses or internal groups - the concept remains).

The diagram shows that the API-Management system is nearly always exposing either SOAP over HTTP or JSON over REST (HTTP). However, the diagram also shows that the back-end services being exposed may be using any old protocol. Indeed, what may be a single service to the API-Manager may actually be a group of services at the back-end. It's at this point that we can see that 'something' needs to understand the back-end services and possibly transform, amalgamate, augment or just log the data going back and forth between the services and the API-Management system. That's the job of an ESB !

Division of Responsibilities

The above diagram shows the ESB sitting between the API Gateway and the services the gateway is hosting. The ESB is implementing what's called the 'proxy' pattern. The diagram also shows that the ESB is transforming the output from the services into something that the API-Gateway can more easily manage e.g. JSON,

By putting the ESB into this location in the architecture the ESB is doing the heavy lifting, leaving the gateway to do just the throttling, usage monitoring etc that API-Management is defined as .

Of course, this is the perfect world view. The fact is that most API-Managers are built on top of ESB technology so they all have some ESB capabilities built-in. At that point it's a judgement call as to how much work you are happy for the gateway to do before you offload it to the ESB. From what I can tell, vendors are moving more and more to a the stricter mode where the API gateway's ESB functionality may not even be exposed to the user at all. Thereby enforcing the cleaner architectural view shown above with the penalty that there is now one more moving part (the ESB) to maintain.

Built-in functions

All API-managers on the market today have some function available to you that could have been done in an ESB. A key function (and one that should really be kept in the gateway) is caching. In addition, there are products out there that allow you to obfuscate data as it goes into and out of the API. This is very specific to your solution but could include things like usernames or other extraneous data that the back-end services expose to the gateway but you don't want to expose to the outside world.

Conclusion

Most reasonable sized APIs are going to require some kind of handling of the data prior to it being served through the API-Gateway. When this happens it's a judgement call as to whether you put that workload into the API-Gateway or offload it into an ESB. Today, vendors are giving you that decision to make because the API-Gateways are built on the old ESB technology and most rudimentary functions are exposed to you in the gateways. I would suggest that adding an API-Manager into your solution doesn't change the fundamentals of what an ESB does for you and will almost certainly not negate the reason to have one.

Update

IBM have just announced a new product with this very architecture in mind - IBM Application Integration Suite. They've added in a cloud based ESB as well in the form of Cast-iron in order to integrate external partners/solutions to your API's.