As discussed in earlier blogs, the key distinction between a managed API and an unmanaged API is that, well, the managed API is “under management”

A managed API has appropriately enforced business and IT controls, which in turn begs the question of where and how those controls are enforced at runtime. Enforcing the controls in code is generally a bad idea. For one thing it is notoriously unreliable, depending on the code quality of every single API implementation. Furthermore, an organization really needs the ability to change the controls without having to change and re-deploy the API itself. In other words the controls should be policy driven with independently managed policies defining the (business and IT) operational intent and the API runtime enforcing that intent. Examples of common policies are the level of security required or the amount of traffic allowed.

A piece of middleware that hosts APIs and enforces API policies is commonly called an API Gateway. The Gateway controls traffic across the boundary between API consumer and API implementation, it enforces the terms and conditions for API consumption defined by the API owner.

Three important characteristics of a Gateway are the following

- A Gateway must must be 100% secure

- A Gateway needs to be policy driven with a command and control type user interface

- Operationally a Gateway should have router like (appliance) characteristics. Low latency, high scalability, high availability, managed by configuration rather than coding.

Historically we have tended to think about different types of gateways as distinct “boxes” in a deployment topology, be that a Web gateway, a security gateway, a messaging gateway or an API gateway. In a hybrid world of devices, people and software that perception of distinct gateway “boxes” is rapidly evaporating. As the scale and variety of interaction grows orders of magnitude, operationally it is advantageous to have a unified Gateway strategy with a single command and control center for any traffic crossing internal or external boundaries. While the management client for creating a connection point on the gateway may be different for say APIs compared to web pages or devices, from an operational perspective different types of endpoints should simply be deployed to different domains within the same Gateway runtime.

Connect with me on @ClausTorpJensen or read my earlier blogs. You can also subscribe to the blog list here