A Bug in the System:: An API Design Capabilities Comparison: Apigee Edge Vs. WSO2 API Cloud

Disclaimer: the information and views presented in this document may not be the same as those endorsed by the owners of the products and should be considered as an opinion of an independent analyst.

Download this technical paper in PDF format, link.

Terminology Map

This sections is meant to debunk a few vendor specific terms,

WSO2 Term	Apigee Term
API	API proxy
Resource	Flow
Message Mediation Policy	Policy
Throttle Policy	Policy
Store	Developer Services Portal
Publisher and Admin portal	Management UI

Introduction

It is justifiable to say that an API’s success or failure is determined by the level of adoption and use it sees, therefore it is also fair to say that API creators should invest a considerable amount of their efforts to ensure they get the developer experience of the API right.

Ovum Decision Matrix: Selecting an Integration PaaS (iPaaS) Solution, 2015-2016 predicts the API Management space to grow at a rate of 40% to reach a market valuation of 940m by the end of 2019[1]. The mediation/transformation capabilities found in many API Management solutions are a subset of those provided in integration products such as ESB’s, therefore it should not come as a surprise that over the years API Management products be it on premise solutions or cloud deployments have started porching into the integration market. This view is reflected in Ovum Decision Matrix: Selecting an API Management Solution, 2016-2017 report, where they predict API Management solutions will need to provide an end to end experience that capture the value proposition provided by middleware stack providers.[2]

The objective of this document is to provide a comparison of the API design capabilities provided by two prominent API management services in the cloud, namely Apigee Edge and WSO2 API Cloud.

Both providers have had presence in the API Management space for a considerable amount of time and have made a name for their offerings. Apigee introduced their solution as a cloud offering prior to moving into the on-premise domain, as opposed to WSO2 who ventured into API Management space as an extension to its on premise middleware product portfolio, they started offering the solution in the cloud from 2015[7].

Method

The research component required for created this document was carried out with the use of free trials provided by the two vendors. Both vendors provide a full access trial that allows users to test drive the product for a predefined period. At the time of writing, WSO2 API Cloud uses an API Manager 2.X build and Apigee Edge, a 17.X build.

Capabilities of each offering was identified by referring publicly available information and through hands on experimentation on the products.

Data-sheet Comparison

Before looking into a few key design capabilities of each offering in detail it’s worthwhile to compare the offerings at a API design datasheet level.

Capability	Apigee Edge	WSO2 API Cloud
Swagger support	Supported	Supported
SOAP endpoints	Supported	Supported
API resource definitions	Supported	Supported
Design validation/testing	Supported	Limited Support
Design import and export	Supported	Supported
Versioning	Supported	Supported
API Proxy path mediation logic definition	Supported	Supported
Backend path mediation logic definition	Supported	Limited Support
Mediation extension	Supported	Supported
Graphical Mediation logic editor	Supported	Limited Support
Security	Supported, requires setting up	Supported
Traffic management	Supported	Supported
REST API support for design functionality	Supported	Supported
Backend mocking	Supported	Supported

Deep Dive: capabilities comparison

The proceeding subsections compares a few key API design aspects of the two offerings.

Swagger Support

In the context of API Management, Swagger support plays two roles, first it allows API publishers to use predefined definitions as a starting point in the publication process. Secondly, it allows Swagger definitions of published API’s to act as a starting point in the discovery and adoption process. Many API management solutions provide functionality dedicated to these very requirements, this is also the case for the two offerings being evaluated.

WSO2 API Cloud

Apigee Edge

Publishers may start the API Creation process utilizing a Swagger JSON upload or a hosted Swagger JSON URL.
API attributes such as resources, context and version are extrapolated from the provided swagger definition.
Allows the publisher to break into an embedded Swagger editor at design time to define resources etc using YAML.
The swagger console in the developer portal gets populated with the content of the definition utilized at design time.

Publishers may start the API Proxy creation process utilizing a Swagger YAML/JSON upload or a hosted YAML/JSON URL.
Attributes such as flows, context and backend endpoint are extrapolated from the provided Swagger definition.
Publishers may define the specifications in the specs section of the management UI prior to creation of a new API Proxy.

Mediation Time Logic Definition

As discussed at the start of this document, API management solutions are venturing into the integration space. The ability to define simple mediation time logic has become a capability many API Management solutions provide.

Both products offer mediation capabilities and mechanisms to define the mediation logic at API design time. In the case of apigee a rich graphical editor is offered to the API publisher, whereas the WSO2 API Cloud provides unrestricted access to many of the mediation capabilities of its mediation engine with the use of message mediation policies.

WSO2 API Cloud

Apigee Edge

Publishers may utilize pre configured Message Mediation Policies that cover some frequently needed scenarios such as XML to JSON conversion and vise versa.
Publishers may attach custom Message Mediation Policies that are written in WSO2’s mediation language.
Message Mediation Policies may be attached to the API’s Request or Response flows.
Backend endpoint request and response mediation logic may be put in using custom Message Mediation Policies.

Policies are provided for frequently needed scenarios such as XML to JSON conversion and extracting content from HTTP header/body components.
Mediation extensions are supported with java script.
Mediation time logic maybe attached to Flows, which include, API request and response paths, backend request and response paths as well as individual resources of an API.

Security

Securing API behind an access control layer is one of the key requirements any potential consumer of such a solution would have. In the space API Management this is achieved using Oauth and its options provided through grant types. The grant types an API should support should be decided based on the manner in which the API is expected to be consumed, as such API Management solutions should provide mechanism to define these attributes at API design time.

Apart from securing access to the API, it’s common for API management solutions to provide, transit security and last mile security capabilities.

Both offerings provide comprehensive security options.

WSO2 API Cloud	Apigee Edge
The publishers are allowed to select oauth options per resource. The solution inherently supports password and client credential grants, others maybe be availed by explicitly calling the oauth API endpoint. Management API are secured in Oauth and in some cases basic authentication. Transient API calls are secured with TLS.	Solution supports API Key and Oauth as security mechanisms. Security mechanisms maybe attached to flows. Endpoints required for oauth should be created/deployed in the environment being used(refer apigee documentation sample[8]). Management API are secured with basic authentication(can be configured to use oauth) Last mile and transient security is provided.

Traffic Management

Regulating the flow of invocations to API is another key requirement of those who seek to employ API Management solutions. The regulation mechanisms may be needed to control the access to the API as well as to ensure the access policies of backend services are not violated.

Both offerings provide a comprehensive set of traffic management capabilities.

WSO2 API Cloud

Apigee Edge

Publishers are allowed to attach predefined throttling policies at API, application or resource level.
Publishers with Administrative permissions may create custom throttling policies editor found in the admin dashboard.
Advanced traffic management requirements such as spike arrest or intelligence based throttling scenarios can be accommodated using custom rules, written in WSO2 stream analysis language SiddhiQL[3](ATM, this feature is only available in the on premise version of the solution).
Response caching can be enabled at API level, to ease the burden on the backend services and increase client response times.
Traffic decision measure can be changed from number or requests to bandwidth if required.

Quota policies can be attached to multiple points such as API, API keys, access tokens and developers.
Spike Arrest policies can be attached to flows to smooth out access to API.
Advanced quota scenarios may be constructed using the policy configuration[4].
Distributed quota counters supported.
Provides concurrent rate limit policies to regulate the flow to backend endpoints managed by the solution.
Multiple response related caching capabilities are provided as policies.

Design Experience

The API design experience is considerably different between the two offerings.

Apigee Edge

Apigee provides an extensive collection of policies related to mediation time logic definition, this aspect of the product pushes its proposition towards that of an integration product such as a ESB. To accommodate its extensive palette of policies in a meaningful way the product provides a centralized API editor.

The publisher first creates a skeleton API design either utilizing a Swagger definition or using the API proxy wizard(figure 1). Once the skeleton API design is in place it may be filled in using the editor(figure 2). The editor provides a graphical representation of the API’s mediation flow, underlying XML configuration and the palette of policies that can be attached to the API’s flows as needed. The design may be validated by deployment and trace capabilities provided. Once the design is validated it may be packaged into a product to be made available in the Developer Services Portal(developer portal).

figure 1

Figure 2

WSO2 API Cloud

The design experience here is comparatively more guided, in the sense the API publisher must follow three predefined steps; design, implement and manage when creating an API(figure 3). At each step the publisher makes decisions pertaining to the areas of design the steps represent. Swagger editor is integrated to the design stage allowing the publisher to access its capabilities in a way which is not possible with Apigee’s offering.

Figure 3

Conclusion

One of the key conceptual differences between the two offerings is in the way some API management aspects such as security, traffic and mediation are defined and offered for the API publishers consumption. Apigee does a weak separation between these concepts at design time allowing the API publisher to use them as components of equal standing when designing API. Further they direct the API publisher’s focus to the definition of the API mediation logic, providing a rich editor. The weak conceptual separation of these areas is also reflected in their terminology where atomic components belonging to seemingly unrelated areas of API design, such as security, traffic and mediation are all referred by the umbrella term “policy”. This weak separation provides simplicity in API mediation design from a publisher’s perspective, and further strengthens the offerings potential as an integration crossover solution.

WSO2 API Cloud, provides a rich set of functional capabilities that align with traditional API Management offerings. Bridging the chasm of a full middleware stack seem not to be an imperative here, as such the offering is on the point and focused on API Management specific needs.

In the case of Apigee Edge, the publisher is provided more flexibility in design and capabilities that cross over to the integration space, he or she is allowed to make more design time decisions, however this flexibility may come at the price of unwarranted complexity for simple API design needs a SME/SMB or a startup is likely to have.

There are no hard and fast winners here, rather the two solutions, with their capabilities and design are suited for different requirements and different types of consumers. For those who require rich mediation logic definition and validation, fine grain control over the design, Apigee Edge may be the better of the two options. If however, the requirements are simpler and are more inline with traditional API Management practices, from a pure API design perspective it might make more sense to go with the WSO2 API Cloud.

Find out more information about the two products and take them for a test driver here[5][6].

Appendix

WSO2 API Cloud Pricing

The prices were extrapolated on the 18th of July 2017 from the official product website. The plan prices are in USD. Apart from the prices listed below, there is a baseline cost of $498 for those who require VPN access to the deployment datacenter.

Plan	Starter	Getting Traction	Medium	Large	Extra-large
Portal users	100	2000	7000	unlimited	unlimited
Maximum calls per day	250,000	700,000	2,000,000	10,000,000	50,000,000
Maximum calls per second	10	25	70	300	1000
Gateway deployment zone(GCP) options	US East only	In one of the following zones, Canada, US East, US West, Brazil (São Paulo), EU (Ireland), EU (Frankfurt), Singapore, Tokyo, Sydney, Seoul, Mumbai	Upto three different zones from the following list, Canada, US East, US West, Brazil (São Paulo), EU (Ireland), EU (Frankfurt), Singapore, Tokyo, Sydney, Seoul, Mumbai	Upto three different zones from the following list, Canada, US East, US West, Brazil (São Paulo), EU (Ireland), EU (Frankfurt), Singapore, Tokyo, Sydney, Seoul, Mumbai	Upto three different zones from the following list, Canada, US East, US West, Brazil (São Paulo), EU (Ireland), EU (Frankfurt), Singapore, Tokyo, Sydney, Seoul, Mumbai
Monetization capabilities	No	Yes	Yes	Yes	Yes
Plan cost per month	$129	$298	$698	$2,980	$9,980