Cloud Blog

All posts by Amila Mahaarachchi

Share your API subscriptions with your team

APIs published in WSO2 API Cloud are secured with Oauth tokens. Therefore, before invoking them you need to subscribe to the API and generate an Oauth token. To subscribe to an API you need to create an application (a virtual one). If you are not familiar with the concepts you can find more detail in our tutorials.

One request we had been receiving from our users was the ability to share these subscriptions with others in their teams. This seemed to be a very valid requirement. Most of the times there is a team who develops an application which will consume these APIs. Even-though one person subscribes and generate tokens to invoke an API, it makes sense for others to have some control on that subscription. For example they might need to re-generate a token due to some urgent security reason or subscribe to another API needed by their application without being by the application owner to do it. Basically, this reduces the impact of a centralized ownership in your API consumption process. After considering this, we have released a feature which allows subscriptions to be shared with the team.

How this works?
When users create applications in the API developer portal they can define a group(s) which they want to share the application with. Here, what is meant by a group is a role in their organization. You can read more about roles and assigning users to them from this tutorial.

If there is a “Finance” role in the organization and if it is provided as the group to share the application (as shown in the above image), then anyone signing into the developer portal who has that role is able to see that application.

Others in the team can see the subscriptions made by this application, view the tokens and also re-generate the tokens if needed. But, if they are not the application owner, they cannot do the token generation for the first time. i.e. It has to be the owner who does the first token generation. Application owner has full control over the application and the others have less control. For example they cannot unsubscribe from an API which was subscribed by the application owner. But the owner can unsubscribe from APIs which were subscribed by others using his/her application.

You can follow the steps in our tutorial to implement this for your organization.

SOAP to REST made easy

WSO2 API Cloud has been a service which allows you to convert your SOAP backends to RESTful, managed APIs as a first class feature. We have published a previous blog post on this and we do have a tutorial too which provides step-by-step instructions on how to get it done. API Cloud is capable of doing this because of the mediation capabilities of the API gateway. This has been a widely used feature so far. But, there were some steps which we thought we could improve. As a result of that, exposing your SOAP backend as a RESTful, managed API now has been made very easy.

Following are the improvements we have done.

  • Previously, users had to create the resources of the API manually. But now, when you provide the WSDL url, API publisher automatically creates the resources by looking at the SOAP operations in the WSDL. Users can then edit the Swagger definition and make changes to the resources names, HTTP verbs etc. if needed.

  • Previously, users had to upload a custom mediation sequence to generate the SOAP payload to be sent to the SOAP backend. Now, this mediation sequence is auto generated by the publisher app and users can change it if needed.

Following is all you have to do after going to the API publisher:

  1. Create an API by providing the WSDL url of your SOAP backend.
  2. Publisher will generate the swagger definition. Edit it as necessary.
  3. Provide the backend service url in the Implement tab.
  4. Edit the mediation sequences which does the SOAP to REST mapping as necessary.
  5. Publish the API.

You can follow our documentation with more detailed steps.

WSO2 Named a Leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report

You may already know that WSO2 API Cloud is powered by the world class open source product “WSO2 API Manager”. When you access the API Cloud, what you get is the hosted latest version of WSO2 API Manager which spans through multiple geographical regions. We are happy and proud to announce that WSO2 was named as a leader in the Forrester Wave for API management solutions, Q4 2018 report. You can download the report (without filling a form) by going to our site.

It is a great achievement for WSO2 to be identified as a leader in API management. This means you are consuming a world leading API management solution when you use the API Cloud.

So, why wait? Try it out today for your API management project too.

Log download feature improved with HTTP access logs

In June 2018, we launched the log download feature for WSO2 API Cloud users. It allowed the users to download the logs of the cloud API gateways. This has been useful to many of our users when investigating and troubleshooting certain issues they face.

We are happy to announce that we have now added the capability to download the HTTP access logs (load balancer logs) of the APIs as well. These logs includes the request paths and the response codes (which you find in normal access logs)  associated with the API requests coming to the cloud API gateways.

When you go to download the logs, you will get an option to select from Gateway and Load Balancer.  Rest is the same steps as in the log download feature.

Next time if your API consumers complain about some of the API requests, these logs will help you to troubleshoot them.

Configure the header to carry the Bearer token

APIs published on the WSO2 API Cloud are secured using OAuth2.0 by default. Any client application invoking a secure published API needs to have a valid subscription to the particular API and present a valid OAuth2.0 Access Token to the API Gateway.

The HTTP Authorization header is the most common method of providing authentication information for REST APIs and it is used in API Cloud as well. The application needs to have the access token in the Authorization header to authenticate the API that is being accessed. But, there can be reasons such as organizational policies, legacy backends expecting to use the authorization header for other purposes and legacy client applications which will force you to use some other header to pass the bearer token to the API gateway.

WSO2 API Cloud now allows you to define your own header to carry the bearer token. This can be configured for the entire organization (all your APIs) or for certain APIs only.

Configure the authorization header per API

When creating a new API or editing an existing API,

  1. Go to the “Manage” tab in the UI.
  2. Provide the name of the header which you wish to use as the authorization header as shown below. 
     
  3. Save and publish the API.
  4. When you go to the developer portal, you will be able to see the portal is ready to send the new header to the gateway.

If you want to invoke the API with cURL, following is the command.

curl  -X GET “<Your API URL>” -H “Accept: application/json” -H “Token: Bearer <Your Token>”

Read our documentation to learn how to configure this at the organization level.

Now that this cool feature is available in the WSO2 API Cloud, you will be able to connect your legacy backends and legacy clients to the API gateway without worrying about the authorization header.

.entry-content img {
width:100% !important;
}

How to avoid your backend endpoint getting suspended by the API Gateway

When invoking an API published in API Cloud, you might have seen the following error response:

<am:fault xmlns:am="http://wso2.org/apimanager"><am:code>303001</am:code><am:type>Status report</am:type><am:message>Runtime Error</am:message><am:description>Currently , Address endpoint : [ Name : somename-AT-sometenant--test_me_APIproductionEndpoint_0 ] [ State : SUSPENDED ]</am:description></am:fault>

As you can see from the message above, the endpoint got suspended. By default, gateway suspends API for 30 seconds when it cannot reach the endpoint. So, if another request comes to your API within that 30 seconds, it won’t be sent to the backend, rather an error response similar to above will be sent back to the client.

If this is not the behavior you want, these rules are simple to modify:

1. Go to API Publisher and select the API that you want to change. Then click Edit from API Overview

2. Under the Implement tab, select Advanced Options on the endpoint which you want to re-configure.

step1

3. Modify the values. If you want to disable the suspension rules, set both Initial Duration and Max Duration to 0:

step2

4. Save changes and re-publish the API.

This way you can tweak the suspension rules or completely disable the mechanism and thus prevent your API from ever getting suspended by the API gateway.

Try it today in WSO2 API Cloud!

Categories

Recent Posts

Most Popular Posts