Conceptual curve

A new front for SOA: Open API and API management as a game changer – Part II

Kai Wähner

The continuation of our deep dive into Open Api – taking a look at the management products.

This is a continuation of Kai Wähner’s article “A new front for SOA: Open API and API management as a game changer” – part one is over here


API Management solutions have to scale. Unlike internal service calls in a SOA, public APIs have other requirements: Service consumers are not known, SLAs differ, and the number of service calls depends on success of external partners and can increase quickly and significantly. Therefore, an API Management solution has to ensure different scalability aspects:

  • No single-point-of-failure
  • Multiple instances of a gateway can be deployed across multiple hosts
  • Can be scaled dynamically to address peak demand
  • Can be deployed across data centers for geo-resilience
  • Allow caching to improve performance
  • Gateways report availability to load-balancer
  • Centralized logging of distributed deployments
  • Infrastructure can be monitored by existing agents and tools

Policy based Service Delivery

The service delivery of open APIs has to be policy based. Depending on the use case, many of the following policy aspects have to be managed in a flexible, configurable way:

Authentication and Authorization

  • Access control granularity down to service endpoint or operation
  • Single-edit configuration changes through web user interface

Throttle Capabilities

  • Rate & high-water mark technical throttles designed to protect particular service implementations
  • Quota commercial throttle designed to prevent commercial over-use of services (e.g. wholesale usage)
  • Time-of-day throttle behavior down during known busy periods or maintenance
  • Error-rate/ payload-size technical throttles designed to minimize impact of external parties
  • Group logical throttle to help manage large partners, large service deployments

Routing Capabilities

  • By operation: Routing based on the requested service, such as a SOAPAction or URL string
  • By requestor: Routing based on the name, type or class of requesting-device
  • By version: Version routings can be used to support multiple concurrent versions of a service or a service implementation
  • By protocol: Routing can be used to safely abstraction requests bi-directionally
  • Time-of-day routing to difference services (explicitly, orchestrations)
  • By identity: Different partners’ and consumers’ can be routed to different services
  • By size: For some requests (e.g. with attachments), requests can be routed by size to appropriate service handlers


Different roles have to be defined for Open API. API consumers represent partners and external developers while API providers can be developers, administrators, or partner managers. Let’s take a look at the functions each role has to accomplish:

  • Developers
  • Provide a catalog for organizing and publishing APIs
  • Supply a repository for documentation, sample code, usage tips
  • Create product options and support plans
  • Provide REST and SOAP service interoperability
  • Monitor and report on API usage and performance
  • Administrators
  • Manage environments and developer accounts
  • Set access rights by user or organization
  • Configure deployment policies for APIs
  • Partner Managers
  • Partner onboarding
  • Community management
  • API Consumers
  • Discover and use APIs
  • Use a self-service portal for enrollment, key requests, and API testing
  • Select product options and support plans
  • Monitor and report on API consumption


Different kinds of API Management solutions are available on the market. More are arising year by year. Analysts such as Gartner and Forrester see Open API as a hot topic for future IT investments and growing revenue.

Let’s recap from above: To realize an Open API solution, you need three components:

  1. A portal (used by API providers to offer API products and by API consumers to use them)
  2. A gateway (configured by API providers)
  3. An analytics tool (used by providers and consumers) to react to feedback, usage and other events

Some vendors offer all these components. Others just offer some of these features. On the one side, there are some vendors “just” offering a portal to publish existing APIs and manage payment / billing. On the other side, there are vendors, which offer a total solution for building services, making them public (including billing), and analytics for improving your services. In between, some vendors offer something “in the middle”.

To make the right selection of an API Management product, you have to think about your requirements and then evaluate corresponding products available on the market. An overview or extensive comparison of different vendors would push boundaries of this article. Though, the next two sections give a short overview about questions you should concern before making a selection, and a short overview of some available API Management products.

Selection Criteria

Vendors differ a lot regarding their API Management offerings. Ask yourself the following questions, decide what you need, and evaluate corresponding vendors with regard to:
  • Do you just want to build a directory for your existing service, or do you want a real infrastructure for building, governing, deploying, and managing your services?
  • Do you just want to publish REST services, or do you also want / have to make other service protocols such as SOAP or JMS public?
  • Do you need a flexible configuration and routing options using different security standards (e.g. LDAP, SAML, Kerberos, OAuth, WS-*, XACML, etc.)?
  • Do you need an elastic highly scalable architecture for millions of messages (based on event driven architecture instead of synchronous HTTP calls)?
  • Do you need to extend the portal to your needs (regarding topics such as service management, developer portal, analytics)?
  • Do you want to leverage other products of the same vendor (e.g. products for integration, mapping, transformation, routing, business processes, complex event processing, etc.)?
  • Do you want to deploy your API Management solution on premise or in the cloud? If in the cloud, is virtualization through VMs fine for you, or do you want a real, i.e. elastic, cloud solution?
  • Do you want a hardware appliance or just software? Is it required to configure your API engine for running in your DMZ on existing servers?

The products

Available products differ a lot in functionality and maturity. A more detailed evaluation is required to make the right decision for your use case. The following is just a short overview of different vendors, which offer API Management solutions (but not a complete list).

Apigee offers a complete API Platform. As the company’s name states, Apigee is focused especially on API Management. The solution is designed to meet the challenges of the new mobile, social, cloud marketplace head-on. Users can start with a (very limited) free version.

Mashery is another solution focused especially on API Management. It was born out of the Web mashup movement of the 2000’s, hence its name. However, Intel Corporation acquired it in 2013. Mashery offers a very affordable and easy to use cloud solution to publish existing APIs. Thus, it is good for simple scenarios. Users can start with a (limited) free version.

Layer7 has deep roots in the XML gateway market and offers many advanced routing and security features. It has extended its product portfolio to API Management. The solution is very powerful, but therefore very good technical knowledge is required.

TIBCO provides a comprehensive operating platform called API Exchange, which lets you build and test APIs, define runtime governance policies, migrate APIs between environments, and monitor and report on API usage. TIBCO API Exchange leverages other TIBCO products to combine ESB, BPM, CEP, etc. with its API Management solution. TIBCO’s products focus on complex enterprise scenarios.

IBM is also focused on complex enterprise scenarios and has different powerful API Management solutions in its portfolio, for example IBM API Management, DataPower XML gateway, Cast Iron Live Web API Services, and others.

Several further vendors offer API Management solutions. Some of the most visible ones are Vordel andApiphany, acquired by Microsoft recently, focusing especially on API Management while Software AG andOracle are examples for other big software vendors which offer not just API Management, but solutions for the whole integration portfolio.

MuleSoft and WSO2 are two open source Enterprise Service Bus vendors, which also included API Management solutions in their portfolio.


Open API and API Management represent the leading edge of a new business model. 

Enterprises have very good opportunities to increase revenue, reduce costs and improve efficiency by publishing and monetizing internal services to external consumers via API Management solutions. Many API Management solutions are available on the market.

Their functionality differs a lot. The products are still young and have to improve in the next months and years – but they are already mature enough for getting started to innovate in creating new business models and increasing revenue. Open API and API Management have a great future!

Inline Feedbacks
View all comments