It has been a busy month for the people at WSO2; the introduction of the new Enterprise Integrator 7.0.0, the upcoming Enterprise Integrator 6.6.0, the Identity Server 5.9.0, and the topic of this blog, the API Manager 3.0.0. We’ll cover what’s new in the new WSO2 API Manager from a high-level perspective. We look at the changes indicated in the release notes and documentation, but we won’t do an in-depth test or experience blog. However, since a pure text blog is boring, I’ll show some screenshots of the Publisher and new Devportal (formerly the Store).
A new version
But what is new in this version? Well, a number of things like:
- – API Monetization
- – JWT Authentication
- – API Schema Validator
- – GraphQL API support
- – Bot Detection
- – API Product
Let’s take a closer look at these functionalities.
Monetization has always been a possibility with the WSO2 API Manager. In API Manager 3.0.0 there is more support for API monetization. We can integrate with a third-party billing engine using the available pluggable extension points in WSO2 API Manager. Payment Provider Stripe is the sample provider for an Out Of The Box (OOTB) version of the API Manager. A very interesting development that we will look into next year and probably also include that in the advanced WSO2 API Manager training that we are updating.
In addition to the possibility to use an Oauth2 token, we now have the possibility to use JWT Authentication as an alternative to invoke APIs. WSO2 API Manager supports the use of self-contained and signed JWT formatted OAuth2.0 access tokens as API credentials. When an API is secured using the OAuth2 security scheme, the JWT tokens that are issued for the users from the Developer Portal can be used to invoke APIs.
API Schema Validation
WSO2 API Manager allows users to use their OpenAPI definitions and enforce the request and response validations without any additional work (for example, implementing custom mediations, etc.). This means that before the call goes to the backend, the schema is validated and in case validation fails, the gateway sends a 400 status code (bad request error), the same applies to the validation of the response, in that case a 500 status code is sent (internal server error).
Next to SOAP, REST and Websockets, users can use GraphQL schemas to design GraphQL APIs in WSO2 API Manager. Thereby, API Manager users can manage their GraphQL services as APIs. GraphQL is a new query language for your API. You can for instance take a MySQL database and put a GraphQL layer on top of that allowing the API to query the database. The GraphQL standard is open but it is championed by Facebook.
To make the API Manager less vulnerable bot detection is introduced. This capability in WSO2 API Manager notifies admin users via email about invocations of open APIs and APIs without proper authentication. These can be carried out by bots and attackers but can also just be a mistake by developers during the development process. There are more improvements in this version that have to do with security like json/xml threat protection.
Mix and match
Another cool feature is the possibility to integrate several APIs and expose them as a single product. Thereby helping to package different services in different ways and exposing them as separate products. This can of course also be done by defining different APIs, but the API Product is a new approach to it.
Back to the API manager
The API Manager 3.0.0 runs on Java 8 and 11. We’ve also seen this behavior with the Identity Server 5.9.0 so we assume that it runs on the same 4.5.1 Carbon core (also known as Minsky). This of course means that we have the deployment.toml to simplify configuration. This allows you to make all configuration changes in one file (deployment.toml) rather than all of the other config files in the /conf directory. The old configuration model is still there and can be used but this is a big improvement.
A number of improvements and general changes have been made to the API Manager, but the most visible changes are in the most used components, the Publisher and the Devportal (former Store). Let’s take a look what has changed.
As long as I can remember the publisher has been the place to define your APIs. This has been a three-step process, defining what the API looks like, where the API is going to run (and points) and finally defining who will have access and to what extent. This is more or less a lengthy process that takes 10 to 15 minutes to fill everything in, at least that is my experience when I’m providing WSO2 API Manager training.
The Jaggery apps that were part of the product have been revamped to ReactJS. The Publisher has a new look and feel and a significantly different approach. Not only do we see a new option when defining an API (GraphQL SDL Schema), when we start defining a new API, we see the difference. The new version of the API Manager version 3.0.0 has something of a short track to that.
Creating or defining an API is done on the high level with only a couple of fields that you need to fill-in. You need to fill in name, context, version endpoint and tiers, something that is now called business plan.
That’s it. But how about all of the other settings that are necessary? Well that’s all done in the next steps.
By default, it will create a get/post/put/delete/head/ on the wildcard resource (/*).
After clicking Create and Publish, the API is available in the Devportal (previously known as the store) as well as in the Publisher. In the publisher you can make changes to the definition of the API as we would have done in the API Manager 2.6.0 as part of a more continuous flow with the three tabs defining an API. All of the options that were available in the older version are now configurable as separate options. Including the new monetization option that is now available.
After the definition we can focus on the subscription in the Devportal. People familiar with the Publisher may be wondering where the Analytics have gone. Previously they were included in the Publisher. The answer is that they are now in the separate Analytics Dashboard rather than visible in the Publisher.
Bye bye Store, hello Devportal
The API store doesn’t exist anymore and has been replaced by a Devportal.
This is the overview, being signed in as admin. Clicking on the API gives you the same kind of overview as we see in the Publisher. The look and feel might be different but the functionality is largely the same.
When we are done defining the API we go to the store to subscribe to the API using an application. You can subscribe to the API using an application, generating Oauth2 or JWT tokens for authorization. After that you can try out the API using the familiar try it functionality.
Hip and happening
The new Publisher and Devportal look more modern and a bit hipper. The improvements made otherwise in the API manager have multiple benefits, from the ability to run on a more modern Java version (11) or the easier configuration using the new toml file. And many, many more. This is the WSO2 API Manager that we know and love, but now even better.