In the answer to @Dino, I had given some reasons why APIs around the ESB endpoints is basically just that -- you might have given a “REST” interface to your endpoints. Even for that exposure, you need to think through the endpoint management that is needed. What is your security model? Is your endpoint being touched from outside the firewall? And even if it is being touched from only inside, do you really trust that it has not been breached? What visibility are you getting? What documentation do you have on your endpoints? You do not get any of it by just putting a REST interface to the ESB endpoint.
And on top of it, you get none of the consumption benefits that a true API should have. A developer portal, keys associated with applications, visibility, APIs as a product -- the list goes on and on.
Finally, the architecture of ESB gets in the way of the right API architecture -- the latter scale, distribute, have self-service models, support the right tradeoffs between exposure and governance concerns.
ESBs can’t solve the API problem. New architectural trends -- many more backends have APIs, integration moving to code, and http based connectivity -- allow you to do in the API layer what you might have thought to do in the ESB layer. And a lot lot more 🙂
LinkedIn
Twitter
