The Differences Between API and ESB Patterns
Anant Jhingran
Arvind Jain
As enterprises embark on their digital journeys, APIs are often used to connect the fast pace of digital innovation with the more stable system of records. This is in contrast with ESBs, which are used to integrate various systems of record, for stable, well-understood business processes.
There are two stark differences between the world of APIs and the world of ESBs:
- APIs are consumption-centric, whereas services exposed through ESBs are exposure/reuse focused.
- The logic for “orchestration” is not a significant driver for the API layer—apps are perfectly capable of calling service1, service2 and then service3, depending on the digital experience they need to deliver. Of course, some amount of orchestration might be present in the API layer, but it is not expected to be the dominant pattern.
You might ask, Anant and Arvind, all of this sounds great, but the proof of the pudding is in its eating, right? You did not think we didn’t have proof, did you?
Consumption patterns in APIs
We analyzed, for the top 450 APIs (based on call volume) of customers, the “structure of the APIs,” and their “orchestration/chaining patterns.”
Within Apigee Edge, an API can be configured to have policies that affect something in the APIs—sometimes to benefit the backend, and sometimes to enable developers to use them better. We classify the former as “exposure-centric”, and the latter as “consumption-centric.”
We classified the over 30 different types of policies that our customers use into four broad categories, and, within them, whether they represent exposure or consumption concerns (the same broad category can have both exposure and consumption policies). As you can see from the figure below, a far larger set of policies affect consumption concerns.
Once again, if you are not thinking consumption, you are not thinking about APIs right!
Lack of chaining patterns in APIs
We also looked across more than 9,000 production-deployed APIs to discern whether they call other APIs, or whether they call target systems directly.
As you can see in the diagram below, chaining is not a common pattern. We do find a few “experience APIs,” and some “orchestration” examples, but they are reasonably rare.
Once again, if you are thinking heavy orchestration, you are thinking ESBs, not APIs.
Apigee has all the capabilities for exposure and API chaining, of course, and it is often used for microservices and chaining calling patterns, but the current dominant patterns are consumption and light orchestration. When the goal is speed of implementation, the Apigee platform, with support for Java, Node.js, and Python, is perfectly suitable for orchestrating services and mashing up content. The Apigee platform provides customers the ability to get into production quickly and to migrate if and when it makes sense to do so.
Special thanks to our head of product strategy Ed Anuff for helping us think through this topic.
For more on the differences between API patterns and ESB patterns, download the eBook "Beyond ESB Architecture with APIs."
