API Connect

 View Only

An ESB is not API Management

By Alan Glickenhouse posted Tue April 04, 2017 07:16 PM

Several years into the era of APIs and still one of the most common points of confusion is the positioning of APIs and Services (and Microservices) and the positioning of an Enterprise Service Bus (ESB) and API Management solution.  Many see the similarities between an ESB and API Management – technologies supported such as REST and SOAP, some commonality in integration capability, and believe that one can play the part of the other.  This is not the case.

Previously I have addressed the positioning of APIs, Services, and Microservices in both video and blog formats:

Please take a look at one of these if this is still an issue you find confusing.


Today I will begin to take on positioning of ESBs and API Management.  I plan to do this in two parts.  In this blog I will discuss what an API Management solution provides beyond what is supplied in an ESB.  Of course there are capabilities in an ESB that are not in API Management as well.  In part two I will explore whether it is a good idea to combine the capabilities into a single product or construct in the architecture.


Let’s start by taking a look at what is causing the confusion.  Can an ESB expose a REST interface?  The answer is “Yes”.  Almost every ESB today can expose REST or SOAP interfaces to a consumer and transform/map this to one or more service calls in the Systems of Record (SoR) returning a response to the called interface in JSON, for example.  Since REST/JSON is closely associated with API Management, there is similarity and confusion.  If the creation of a REST API interface were the only thing that an API Management solution provided then an ESB would be sufficient.  But, this is not the case.


So, what else does an API Management solution provide that is not provided by an ESB?  Here are just some of the high level additional capabilities provided:

On top of all these capabilities it should also be noted that an ESB is not the only technology inside or outside the enterprise that can create a REST interface.  Other technologies such as application servers (e.g. WebSphere Application Server), packaged applications (e.g. SAP), SaaS applications (e.g. Salesforce), and Mainframe transaction systems through z/OS Connect can all surface REST interfaces.  All of these REST interfaces can be brought into an API Management solution (such as IBM’s API Connect) for the advantages it provides in enabling the simple and secure consumption of the APIs.


Finally, let’s discuss Governance.  An ESB is a central component of an SOA architecture connecting back end SoR together.  The ESB is in effect part of the SoR, coordinating transactions across applications and ensuring data is in sync.  The ESB may also contain business logic or other programming to fulfill its purpose.  Changes to ESB connectivity flows are governed strongly as are changes to the SoR itself to ensure these changes do not cause problems with the systems running the business.  API Management on the other hand requires a lighter weight governance to meet the need for speed.  (IBM has been referring to this as “two-speed IT” for several years.)  APIs do not contain business logic and are not part of the SoR.  They simply expose SoR data and transactions for simple, secure and controlled consumption.


See part 2 of this discussion, “Is a Combined ESB and API Management a Good Idea?


To understand more about IBM’s thoughts on the API Economy visit the IBM API Economy website.  IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs.  You can find more information about IBM API Connect at the API Connect website.  And you can also experience a trial version of API Connect.


If you have questions, please let me know.  Connect with me through comments here or via twitter @Arglick to continue the discussion.






Mon October 01, 2018 12:10 PM

Alex, Thanks for the comment. This post was focused on the functional differentiation between the 2 architectural constructs. Each of course also has non-functional requirements that are critical to the success as well. I wrote this because I have been seeing people confused by the positioning and wondering if one can do the job of the other or if only a single product is required.

Sun September 30, 2018 09:25 PM

Hi all
I agree with you.
The api gateway is expert in the functions that you have cited.
An esb can even reach them but I imagine it's not your purpose to worry about all those non functional requirements.
Thanks for the opportunity

Wed May 16, 2018 11:43 PM

Jason, I appreciate the comment. You are always welcome to disagree. But, I'll stick with my original opinion too. Security, Rate limiting, traffic management are things you want to happen before you reach the ESB, and for traffic from outside the enterprise before you get into the trusted zone. Otherwise you might get performance (and security) exposures by having too much or unauthorized traffic reaching your ESB before it is turned away.

Wed May 16, 2018 01:49 PM

It does not seem accurate to me... for example, all the capabilities listed under "API Gateway" can be achieved using ESB.