Cloud Blog

Retrieving REST Parameters in JavaScript API Prototypes

JavaScript prototypes are a great way to quickly try your API ideas and collect community feedback while working on the proper longterm implementation.

And good prototypes obviously produce meaningful outputs based on supplied parameters. In this blog post, we will show how you can access REST parameters from the prototype code.

There are two kinds of REST parameters:

  • Path parameters: for example,, and
  • Query parameters: for example,

WSO2 API Cloud obviously supports both. Let’s have a look at how you deal with them:

Path Parameters

You add path parameters in {} brackets when supplying URL Pattern for your API definition:

Adding path parameter

To edit the actual prototype implementation, on the Implementation step, you pick Prototyped API and the Inline option:

Path parameter prototype code

Here’s the code sample that we used:

mc.setProperty('CONTENT_TYPE', 'application/json');
var id = mc.getProperty('');

mc.setPayloadJSON('{ "data" : "' + id +'"}');

As you can see, we retrieve the path parameter as property.

Once we publish the API as prototype, we can invoke it in API Store and see it working:
Path parameter invoked

Query Parameter

Query parameters are great for optional parameters that are named and can be used in any order. These are the parameters, added in the end of the query in ?parameter=value format.

You add these parameters using the Add Parameter button for the API resource:

Adding query parameter

On the Implementation step, we pick the Prototyped API / Inline option and provide the JavaScript code:

Query parameter prototype code

As you can see, the code is very similar to the one we used for path parameter. The only difference is the way we retrieve the parameter. This time, we address it as query.param.mask:

mc.setProperty('CONTENT_TYPE', 'application/json');
var mask = mc.getProperty('query.param.mask');

mc.setPayloadJSON('{ "data" : "' + mask + '"}');

Once you deploy the prototype, you can invoke it in API Store and see it working:

Query parameter invoked

Have an API to prototype? Try it in WSO2 API Cloud!

WSO2 Cloud Incident Report: Jan 21, 2016

WSO2 Cloud faced a serious degradation of service due to DNS failing to resolve addresses related to WSO2 Cloud URLs on 21st January 2016. Here is the incident report and actions taken.

Start time: January 21, 2016 0923 PST
Recovery time: January 21, 2016, 1001 PST


  • Reachability to all WSO2 Cloud functionalities was disrupted.
  • Partial service downtime due to DNS resolve failures for some parts of the world.
  • There was a 38-minute gateway downtime during this incident :

Root cause:
Verification failure between WSO2 name-service provider and ICANN has resulted in disabling of WSO2 domains. Since WSO2 Cloud is run under a subdomain of WSO2 Cloud was also impacted with the domain disabling. It is observed that this has not affected to some regions because caching servers were still resolving for those regions.


  • As soon as our monitoring tools alerted us regarding the outage we escalated it to our infrastructure team.
  • They managed to resolve the situation by contacting the relevant parties and getting the services up.
  • Infrastructure team updated the contact details for the internet domain to ensure that verification calls always reach the team.

API Management Overview Video

We created a short overview video of what API management is, why companies need it, and obviously what makes WSO2’s solution special. Check it out – and obviously hopefully you will find it useful for conversations within your own company:

We are now planning to redesign the API Cloud homepage to give this video a prominent place on it. We’ll be happy to hear your feedback on how well you think it covers the main concepts of API Management and WSO2 API Cloud.

WSO2 Cloud Incident Report: Jan 12, 2016

WSO2 Cloud experienced a serious service degradation on 12th January 2016: users were not able to login to the cloud for few hours.

Start time: 12th January 2016, 0833 PST
Recovery time: 12th January 2016, 1217 PST


  • Users were not able to log into the cloud,
  • Sign-up was not working,
  • API Gateway was functioning throughout the incident serving API calls at normal performance level. There was only a 5 minute gateway downtime during database restart:

Root cause:

  • One of the housekeeping tasks running in our Identity Servers has failed due to a failure in acquiring a lock on a database table. This locked table is also responsible for storing the sessions and since it was locked, system was not able to complete the new user logins.
  • Since it was not possible to find out, which component was keeping the table locked, we had to restart the database server to get the system back on track.


  • We have decreased the frequency of the aforementioned housekeeping tasks as advised by our Identity Server team.
  • We have also raised a support ticket with our internal support team to fix any possible future failures for this task.
  • We are investigating further to figure out which component had the table locked and to fix it.
  • We are looking into alerting and maintenance processes to ensure quicker resolution time in the future.

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=""><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.


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


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!

[Video] Configuring Self-Signup for API Store

What is your strategy for bringing subscribers to your API Store?

While internal and select-partner API programs likely only want to invite developers manually, there are many public API programs in which publishers would like developers to be able to find the developer portal and sign-up themselves.

There is also a variation of the latter case, in which you want anyone to be able to submit a request to join the community, however, the administrator needs to approve the request before the developer can join.

WSO2 API Cloud supports all three scenarios:

  1. No one can sign up, members are invited by admin – this is the default mode,
  2. New members can sign up, but need to be approved by admin,
  3. New members can sign up and get immediate access.

To enable scenarios 2 and 3, click the Configure / API Store Access menu in API Cloud, and follow the instructions.

Below is a quick video demonstrating the whole process:

If you prefer to read step-by-step instructions instead, you can find them in our documentation: Enable Self-Signup to the API Store.

Try it in WSO2 API Cloud today!


Recent Posts

Most Popular Posts