A first look at WSO2 API Manager 1.10.0

Last month, almost quietly, the new version of the WSO2 API Manager was introduced. Although this is a minor update (1.9.1 to 1.10.0) there are a number of improvements and additions that are worth mentioning. We will look into this new version from a bird’s eye perspective and in later articles zoom in on the new features.

Carbon

Although this is a minor thing, the previous API Manager was one of the last products that ran on the Turing (4.2.0) carbon version. Version 1.10.0 supports the new 4.4.0 (Wilkes) version of carbon and with that also Java 8 (Oracle’s version, not Open JDK). This is good news since Java 7 is already quite old and now we can run API Manager 1.10.0 together with DAS 3.0.0 and Identity Server 5.1.0 all on Java 8.

Data Analytics Server (DAS)

Speaking of WSO2 DAS, the role of DAS has expanded and integration with the API Manager has become more easy. The previous version of the API Manager had an awkward connection screen (needed to leave some of the fields on screen empty on purpose) to make the connection between API Manager and WSO2 Data Analytics Server.

You need to make the connection, of course, because DAS (and its predecessor BAM) provide the analytics for the API Manager, like the number of invocations of an API and so on.

In the new version of API Manager, there are actually two ways of making the connection between DAS (BAM is no longer supported): the original way where data is stored in a RDBMS table where from where the data was retrieved by the API Manager and the new way that directly takes the data from DAS using the new DAS REST API.

The new connection screen is nicer and the process of making the connection between the two products makes more sense. However, the documentation leaves something to be desired.

A first test however seems to show that the connection is not flawless yet.

Support for monetization

Another important feature is the support for monetization. This is again done via DAS and will aggregate the data and you are able to forward it to a 3^rd party billing engine. There is a possibility to indicate that users can exceed the number of invocations defined by the tier and get billed accordingly. This allows for a model that is well known from the telco industry: a subscription for a number of calls and additional charging when more is used.

Throttling Tiers

Adding a throttling tier is now simpler. Rather than editing it in the TIERS.XML file, you can now specify it in the Admin Dashboard.

API Lifecycle

The standard API lifecycle in the API Manager (CREATED, PROTOTYPED, PUBLISHED, BLOCKED, DEPRECATED, RETIRED) can now be extended with your own states, e.g. Published to DEV. In these states there are the following extension points that can be used:

1. Define your own life cycle states in the API life cycle
2. Change the state transition events as per the environmental preferences
3. Add custom checklist items for specific state transitions
4. Change the execution code for each state transition

This will allow for a more tailor-made approach to API lifecycle management.

Dynamic Endpoints

API Manager now supports dynamic endpoints. Define the endpoint as a Default endpoint and it sends the message to the address specified in the To header. For that you need to upload the sequence file to the message mediation policy for the specific API.

Mediation Extensions on all or a single API

In previous versions, mediation extentions where already possible for all (and single APIs). In the new version it is also possible do define message mediation policy specific to one API.

Hard throttling limits

Another novelty is the hard throttling limit. When users stay within their allotted number of requests (or tier) a situation can occur that the total calls of all users exceeds the back end’s capacitity. The hard throttling limit will make sure that at that point access is blocked and the backend system remains alive.

HTTP Patch

API Manager now also supports the HTTP Patch verb, allowing for partial updates of a resource.

New REST APIs for Publisher and Store

In this version, the REST API was developed as a APACHE CXF REST web application running on WSO2 API Manager. This API comes with a pluggable security mechanism (a CXF handler), so you have the possibility to to plug in custom security mechanism (write their own handler and add it to web service).

The current API manager REST API web applications will by default, have 3 security mechanisms:

1. Basic authentication
2. XACML for fine-grained permission validation
3. OAuth with scopes support

As said, you can change configuration and select the required mechanism or write your own handler.

Nice improvements and features

All in all, there are a number of improvements in the new version of the API Manager and in subsequent articles we will look into them in more detail.

Want to stay in touch? Join the WSO2 Community today, it is free!