Random Thoughts‎ > ‎

API vs. ESB (and other related tools)

posted Jun 16, 2017, 1:04 AM by Alar Raabe

I would like to clarify some questions related to API management,ESB and specific service interfaces.

From one side, API (Application ProgrammingInterface) is nothing more than a specification a text, containing a set ofmore or less formal statements, which specify the available (service)operations and data that flows through the interface when these operations areperformed.

Therefore managing an API is nothing morethan managing any other formal document which can be done using any basictext editor or something more fancy, called API management tool, with lots ofbells and whistles and with heavy price tag. 

From another side, ESB is nothing more thana system that transports and routes service requests, and returns matchingresponses, usually providing several different physical mechanisms to do so, independentof how these service requests are defined or do they together at all form anAPI.

Therefore, if we implement API managementtool and ESB, then this will not in any way result in a specific API (or service interface). 

Developing a specific API is quite time-and resource-consuming task, which needs to be planned and designed as anyother large development. What makes API design even more important, is thatAPI's guide the architecture of future developments and affect strongly theirproperties.

A good analogy here is with DBMS and actualdatabase schema although we have tools for designing database schemas(e.g. ERwin) and DBMS to run these schemas (e.g. Oracle or TeraData), we cannot assume,that database schema (e.g. for Enterprise DW), suitable for current and future needsjust emerges from separate developments. It needs a special (some-time verylarge) effort, to develop a suitable concrete data-base schema.

API design and development requires sameway as data-base schema design and development:

conceptualmodels for both functionality (service operations) and data (information),

logicalmodels that specify the interfaces, and

physicalmodels that specify the interfaces for specific implementation technologies.