…or how to choose between API Management and ESB

Recently we had to find a way to decide on how to use our integration solutions depending on the API use case to implement at one of our customers, a federal government institution in Belgium.

We will guide you through our reflection and present you with the resulting architecture.

What are our needs?

To define how to use our solutions we need to define our needs.

We have two areas where we expose APIs:

External APIs

Are used to connect with external stakeholders and are business driven.

Internal APIs

Are used to modernize our architecture and are ICT driven.
We are currently in a process of modularizing our backend applications and have defined that the interactions must go over APIs where possible.

Required capabilities:

  • Security
  • Measurement (Logging, Monitoring, Reporting & Analytics)
  • Quality Of Service (Traffic Management & Threat Detection/protection)
  • Mediation (Service Routing, Service Orchestration, Interface Translation)
  • Life Cycle Management (publication, version management, …)
  • Developer Enablement (Self-support, Collaboration & community, documentation)
  • Monetization

API Gateway vs ESB capabilities

API management tries to solve the problem with regards to publication, distribution and use of APIs

ESB tries to solve the issues with regards integration. Typically, it addresses mediation (VETO-pattern), orchestration:

  • Validate
  • Enrichment
  • Transform
  • Operate

The term API has no fixed definition, but it is typically used to identify an autonomous piece of functionally that can be used by others through a REST interface.

Decision

ESB is stronger at VETO patterns, API Management is stronger at all other capabilities including security.

Based on that we have defined that all APIs must be on the API management layer and if the VETO pattern is involved, then the ESB will be involved behind the API Manager.

It is not a rule written in stone and will be evaluated case by case.

  • Peer to peer integration can still be used between backend application if the APIs involved are not reused elsewhere.
  • ESB can be called directly if there is no added value to pass through the API Manager.

This design is summarized in below picture:

Conclusion

If you know your needs and match them to platform capabilities, it is easy to come with a default design.
Still you must be flexible, you design will not always apply to real use cases or architecture. It will guide you through a healthy set of questions to make your decision.

Author: Antoine Wils