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 Programming Interface) is nothing more than a specification a text, containing a set of more or less formal statements, which specify the available (service) operations and data that flows through the interface when these operations are performed.

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

From another side, ESB is nothing more than a system that transports and routes service requests, and returns matching responses, usually providing several different physical mechanisms to do so, independent of how these service requests are defined or do they together at all form an API.

Therefore, if we implement API management tool 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 any other large development. What makes API design even more important, is that API's guide the architecture of future developments and affect strongly their properties.

A good analogy here is with DBMS and actual database 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 needs just emerges from separate developments. It needs a special (some-time very large) effort, to develop a suitable concrete data-base schema.

API design and development requires same way as data-base schema design and development:

conceptual models for both functionality (service operations) and data (information),

logical models that specify the interfaces, and

physical models that specify the interfaces for specific implementation technologies.

Comments