Everything an API can Do can be done by ESB. Then why API Management?

Not applicable

Hi ,

May be a basic and stupid questions for most of you API Techies . I am new to API so need to clarify this doubt . Please Help .

I am basically an integration professional and after going through a lot of videos/blogs/websites , I don't think that APIs are as good or better than ESB .

APIs are more kind of webservices called over http.There are limited adapters in API unlike ESB tools like IIB.

Example is : SAP adapter, Siebel Adapter also apart from web services there are file transactions and others protocol supported in IIB .

Can somebody explain me why API then?

2 11 4,443
11 REPLIES 11

sidd-harth
Participant V

Hi @Baidhya Nath Nayak

I strongly recommend having a look at the following:

https://apigee.com/about/blog/cto-musings/differences-between-api-and-esb-patterns

http://pages.apigee.com/rs/apigee/images/API-43811_eBook_Beyond_ESB_Archit_FINAL_V4.pdf

My personal comment would be that you are concentrating too much on the low level implementation aspects of an HTTP communication - therefore concluding that an ESB exposing an HTTP adapter can do the job. However this is a very limited view. In order to see the benefits of an API management layer, you need to consider the bigger picture, e.g.

  • are you doing systems integration or fast/secure exposure of internal data and functionality to wider audience, aka "developers".
  • "Wider audience" is one of the key concepts. It comes with onboarding (apps and their developers), visibility (analytics) and management (you are not talking about handful systems doing point to point integrations anymore) problems.
  • fast/lean runtime or heavy code/integration scenarios
  • 2 speed IT: fast turnaround/agility to adapt consumer or business needs vs slow change in enterprise SDLC. Search for 2 speed IT to understand more.
  • More focus on interface simplifications for easier consumption vs point to point integrations between multiple systems.

This is clearly a much broader topic but hope this gives some pointers to investigate more.

Actually the CTO was UNVBELIEVABLY WRONG on this! API Chaining has existed since 2014 and I have been talking about it at API World, API Days, RestFest, SpringOne and multiple other Meetups and conferences. There is tones of documentations on API Chaining and open source code as well...

Documentation - https://orubel.github.io/Beapi-API-Framework/chain.html

Youtube video - https://www.youtube.com/watch?v=O4qNQUhxcRg&t=6s

Conference Slides - https://www.slideshare.net/bobdobbes/api-chainingtm

More Conf Slide - https://www.slideshare.net/bobdobbes/api-abstraction-api-chaining

Chaining in API's requires the request/response be reused and that required rewqriting the API Pattern for distributed architectures by solving the architectural cross cutting concern in the original API pattern.

The fact that the CTO of APIGEE is this clueless not only about the API pattern but about the fact that API Chaining was introduced to the industry about 5 years ago is astounding!

If he reads this or any engineers from Apigee read this, I am free to stop on by and talk to your teams. I have talked to other teams at Mulesoft, Mashery/Tibco, AWS Gateway Team, Netflix, VMWare and others.

Just drop me a line.

Your question suggests an ESB-centric perspective. If what you want is to connect system A to system B, that is what ESB's are designed to do, and you should use an ESB to satisfy that need. An API Management system including an API Gateway, will not provide a "better ESB". Comparing an API platform to an ESB platform, using the strengths of the ESB as the comparison criteria, will yield an unsurprising result.

But what we have observed is that, rather than focusing on interconnecting systems, customers now want to focus on transforming into a more agile, digital business. This means developing the ability to expose new capabilities as easy-to-use APIs, to allow rapid self-service consumption of those APIs, and to monitor and visualize the usage of those APIs. The combination of those three disciplines enables an iterative process, via which feedback is continuously injected back into the system. This allows rapid, low-cost experimentation and organizational learning. This is a key part of being a digital business.

You can read more about APIs versus ESBs in other places on the Apigee website. HEre are a few examples.

Not applicable

Found this old thread. The answer on the question is from my experience is rather straightforward: any decent ESB can serve as an API gateway with proxies + policies reused/enabled, logging, performance analyzis done et cetera. But if there is no central ESB solution deployed in your organizazion, then you probably better go with just the API gateway, it will be cheaper and easier to start with. But in this case any endpoint connections and protocol mapping will be more costly to implement because unlike ESB it will be your responsibility to create and maintain such connectors. There will be no centralyzed repo for transformation and workflows connection toloplgy either, because API gateway simply does not have this.

Thanks for taking the time to contribute your viewpoint !

I was browsing and saw this old post. I came from an integration background and have worked on a number of ESB solutions utilizing IIB, WebMethods, and Tibco. My view is that API Management is a layer on top of ESB. ESB allows for transformation and orchestration among various systems to expose some capabilities. These capabilities are exposed as APIs and managed at the API Management layer for consumption.

Incorrect. API MNGT is usually UI/UX for handling caching, hooks, roles, etc. ESB is faster than Web API's as it uses a different protocol than HTTP but HTTP API's are FAR more flexible and universal and easier to implement. which is why they are more widely used.

Plus if you implement the pattern properly to abstract the communication logic from business logic, you get speeds closer to ESB : https://www.slideshare.net/bobdobbes/api-pattern

Why use webmethod when you already have Apigee?

APIgee is EXPENSIVE!!! And is not even that good of a product. They use an archaic API pattern that is not meant for distributed architectures and cannot synchronize their schema/state across distributed services leading to elevated privileges and other issues.

See this for additional info: https://www.slideshare.net/bobdobbes/api-pattern

Thanks for your comment Owen.