The WSO2 API manager 4.0.0 brings significant changes over the previous 3.x.0 releases. One of the major changes that we see now is that the integration profile and the API manager profile are closer together. On the other hand, the Internet has little notion of distance.
By this I mean that whether a proxy is running on the same server or on a different server in a different data center really doesn’t matter. In this blog I’m going to look at what I would call the bread and butter off the API manager, creating an API of course.
What is new? How did creating an API, change? Are there new things we can do and old things we cannot do anymore? Let’s dive in and find out, shall we?
New architecture
In the documentation you’ll find this overview of the new architecture where you can clearly see the presence of streaming integrator and micro integrator. However, it is not part of the download.
When you look at the installation of API manager 4.0.0, you’re looking at a 432-megabyte download , this is roughly in line with the download of the API manager 3.2.0 (445MB). So, it doesn’t seem that whole lot has been added unless of course something has been swapped out.
According to the compatibility matrix API Manager 4.0.0 works for Java 8 and Java 11. According to WSO2 API Manager 4.0.0 is based on WSO2 Carbon 4.6.1 and is expected to be compatible with any of the WSO2 products that are based on any Carbon 4.6.x version.
In order to keep it manageable I’m going to focus on creating an API identifying the changes that are there. I will not look into the myriad other changes in the product.
Starting up the API manager
With my current Java version (AdoptOpenJDK, build 1.8.0_282-b08) I’m starting the API manager. Here we find one of the first changes the familiar wso2server.sh or bat has been now being replaced with a new command apimanager.sh or bat. We simply need to click on the file or started from a terminal session if you’re running on Linux.
It is actually starting like we used to know with the publisher dev portal and carbon console being shows as URLs.
- [2021-09-07 10:45:39,559] INFO – CarbonUIServiceComponent Mgt Console URL : https://localhost:9443/carbon/
- [2021-09-07 10:45:39,559] INFO – CarbonUIServiceComponent API Developer Portal Default Context : https://localhost:9443/devportal
- [2021-09-07 10:45:39,559] INFO – CarbonUIServiceComponent API Publisher Default Context : https://localhost:9443/publisher
Let’s start the publisher
So, there is a new interface that we can see when we log in. The images are new; however, the functionality is partly same. In previous versions we were able to create rest APIs work with soap services [I do not call this API’s because APIs for me are purely rest], graph QL was also available. Only the streaming API is new but when we click on it, we find another possibility that we were able to use namely Websockets.
Clicking on each tile, really shows you what you can do:
and as you can see it is a combination of familiar functionality together with some truly new functionality like webhook API, SSE API and async API. These are truly new and offer new functionality again I’m not sure whether I would call them API’s per say because of the aforementioned marriage of API to REST. But nevertheless, it is an extension of the product. For this first blog on API miniature 4.1 I’m going to focus on the true rest API starting from scratch.
Creating an API from Scratch
So, let’s design a new API. Click on start from scratch and let’s see what the next window holds.
Well, I would say this is a familiar interface in comparison with the previous interface we now have a smaller list to enter as the business plans are now no longer part of the first step.
So, let’s create a first API called myfirstAPI. Fill in the details like this.
Press Create & Publish and you can see that the API is created.
We can try out the API straight from the developer portal. This, however is not new functionality; The feature has been available in 3.2.0 as well.
As you can see from the overview the familiar wildcard resources are created on GET POST PUT DELETE and PATCH as well as the business plan that is now set to unlimited. This does allow you to quickly create an API, but the real world uses of such an API are extremely limited.
I am going to delete these wildcard resources and simply add a GET with a / . Also because the resource gets attached to the URL in case of a GET. This would require mediation to remove (REST_URL_POSTFIX). I am not going to show all steps, simply go to Resources and delete the wildcard resources for all the HTTP Verbs. Add a GET with a / and save the changes.
The reason why I say this, is that both the wild card resources as well as the unlimited business plan are a typical “don’t do that” when it comes to API definition. You really want to tie the resources down as much as possible, only offering ones that are compatible with the back-end and while also restricting the criteria of inputs accepted by said resources. The unlimited business plan is also something that you would not typically use since it takes away the capability of throttling.
But let’s try out our API anyway since this is just a simple test setup. Let’s select the try out functionality from within the publisher. You can find it in the left bottom corner just above the life cycle tab.
I’ve generated the key which is a JWT key that is needed to invoke the API because it is enabled by default. Let’s click on the get button.
As you can see the GET resource of the API is invoked successfully.
Now, let us look how the new API Manager lists the API elements.
New layout
With the new release, publisher layout has now been refreshed. Let’s look at some of the new interesting additions introduced with the new release.
First of all, lets look at the basic information.
This includes the GitHub URL and Slack URL. Other than that, we find the familiar elements of the API definition.
Diving into all aspects will go a bit too far. If you are interested, you can always join our API Manager 4.0.0 CORE training to learn about all aspects.
The following options have also stayed the same, some with a slight change as far as the order of fields go:
- Business info
- Subscriptions
- Documents
- Comments
- Runtime
- Resources
- API Definition
- Endpoints
- Local Scopes
- Properties
- Monetization
- Lifecycle
- Try Out
Deployments
Deployments is new in this API Manager version. Since the API now is created in memory (and not as a file based API Definition in the Synapse directory) we now can deploy Revisions. I have created the API with a new image and deployed that as a revision.
This was the old API from the perspective of the Devportal.
Now it looks like this. Note that this stays within the published Lifecycle. I can switch between Revisions and deploy entirely new Revisions.
What does the documentation say about Revisions? Well, quite a lot actually. The link shows all information but what is most important is the following. To quote WSO2:
With the introduction of API and API Product Revisions, previously coupled publishing and deployment operations have been decoupled. The API publisher has more control over the API deployments and has the ability to introduce recoverable changes to the API project. API revisions are similar to a checkpoint in time capturing the current state of the API when the revision is created.
If the changes have an adverse effect to the API once it is deployed in a Gateway environment, you can quickly revert to a previous state of the API. In total you can have up to five Revisions, after that you need to remove one of the revisions.
By defining multiple gateways, you can test a revision on one gateway and, if successful, deploy it to the other.
Finding the API
The API definition is stored in the governance Registry, under /_system/governance/apimgt/applicationdata/provider/admin directory to be precise.
Conclusion
API Manager 4.0.0 generation is a major upgrade over past versions. There are a number of things that have change. Some cosmetic, some as we just saw, are new procedures and possibilities.
NOTE
NOTE : This blog has been updated, mainly because of the fact that the original API used in this example was not configured correctly anymore and we had to exchange it with another API. Also, we reverted back to API Manager 4.0.0 as we will cover API Manager 4.1.0 in a separate upcoming blog.
