Cloud Blog

Unlimited tier on API, resource, and application level

WSO2 API Cloud’s gateway is capable of enforcing various policies and throttling / rate limiting is one of the most frequently used.

Today we are making Unlimited tier available in each of the policies so throttling is off by default but can be turned on whenever you need them.

Here’s a quick overview of how you can set each of the limits:

API-Level Throttling

These are the subscription tiers that you make available to each of your subscribers for a particular API: for example, 20 calls per minute.

You pick which of them you make available on the final step of API editing:

API-level throttling

You can edit these tiers by following these instructions.

Backend Hard-Limits

That same API configuration page also allows you to set limits across all subscribers of the API – so your backend does not get overloaded by multiple users:

API backend hard throttling limits

 

Resource-Level Throttling

On the other hand, in some cases, you might want to go more granular and set limits on individual REST resources. Again, you can do this in the lower part of that same configuration screen:

Resource-level throttling

These resource-level tiers can be edited as explained here.

Application-Level Tiers

Finally, API subscribers can also set throttling limits across their applications – this way they can prevent abuse of subscription limits by their individual end-users and applications.

These limits can be set in Developer Portal (API Store) on the My Applications tab:

Application-level throttling

Application-level tiers can be edited as explained here.

Notes

  • Like I mentioned before, these throttling limits have been in the platform for a long time. What is changed now, is us making them all off (or unlimited) by default, so you only get limited by the policies that you explicitly set.
  • There is obviously the overall calls per second limit of your API Cloud subscription level.
  • If multiple throttling policies apply – the most restrictive wins.

 

Certificate-Based API Gateway to Backend Authentication

WSO2 API Cloud now officially supports Mutual SSL as one of the options to authenticate API gateway to your backend service.

The way this works is illustrated in the diagram below.

Basically, API Gateway in the cloud is handling user requests, gets users authenticated via OAuth, enforces various policies and so on. However, in its turn, it should get authenticated to the actual backend service. We have long supported various security mechanisms for that including basic authentication, OAuth, IP whitelisting, and digest authentication. We are now adding mutual SSL authentication to the mix:

Mutual SSL authentication between gateway and backend

 

To set it up:

  1. Use the Support menu in API Cloud to create a request with WSO2 Cloud team,
  2. Let us know your backend hostname,
  3. Once we respond via email, send us backend certificate with which you want to configure mutual SSL (your_backend_cert.crt),
  4. Once we have this, we will add your certificate to our servers and send you our public certificate,
  5. You add WSO2 Cloud’s public certificate to your backend servers.
  6. Now you can use Mutual SSL Certificates as a way to secure your gateway to backend access.

If you have any questions, just contact us via the Support menu and we will be happy to help you out.

WSO2 Cloud Webinar Recording: Latest News and Roadmap

If you missed the webinar on our latest updates and future roadmap – here’s the recording that you can watch:

WSO2 Cloud News and Roadmap Webinar Recording - May 2016

The webinar page has both the slides and the video recording.

In the webinar I:

  • Talked about
  • Demoed how they all work together within a sample application,
  • Covered future roadmap of these offerings as well as the upcoming:
    • Integration Cloud,
    • Identity Cloud,
    • Device Cloud.
  • Answered a lot of questions!

So if you could not join the webinar live, check it out here.

 

 

Customize API Lifecycle

WSO2 API Cloud comes with full API versioning and lifecycle management support, allowing you to take your APIs from initial prototypes to testing, publishing, and eventually to getting replaced with newer versions, deprecated, and retired.

You can find video and step-by-step tutorial on API lifecycles in our documentation.

Here is what the default state/transition diagram for any API version looks like:

Default API Lifecycle state and transition diagram

Today we are taking it a step further and allowing you to customize your API lifecycles: changing the states, their transitions, and prerequisites.

To edit your API lifecycle:

1. Go to API Cloud’s advanced Management Console,

2. Log in with your domain-qualified name (shown at the top right of the API Cloud’s main screen, looking like myname.emaildomain.com@companyname) and your regular WSO2 password,

3. In the Advanced Management Console, go to the Extensions tab at the left-hand side, and click Configure / Lifecycles:

Management Console - Extensions - API Lifecycle

4. Click the View / Edit action – you will get an edit box in which you can make changes to the lifecycle flow:

Edit API lifecycle model

5. As you can see, the model is relatively simple. It consists of the set of states (Created, Prototyped, Published, and so on). And the states have their elements: check box items and supported transitions.

For demo purposes, let’s edit the Published state, so instead of deprecating APIs it allows us to directly retire them.

For that, we go to <state id="Published">, and change:

<execution forEvent="Deprecate"
class="org.wso2.carbon.apimgt.impl.executors.APIExecutor">

to:

<execution forEvent="Retire"
class="org.wso2.carbon.apimgt.impl.executors.APIExecutor">

And:

<transition event="Deprecate" target="Deprecated"/>

to:

<transition event="Retire" target="Retired"/>

6. Click Save to apply the changes,

7. To make the new workflow load into your cloud organization, log off from API Cloud, and then log on again in about an hour.

8. Now open one of your published APIs in API Cloud’s Publisher, and go to the Lifecycle tab.

9. If your changes propagated, instead of the Deprecate button:

Before API lifecycle change - Deprecate

You should see Retire:

After API lifecycle change - Retire

For more information on Extending API lifecycles, see the corresponding documentation for API Manager.

Try it in WSO2 API Cloud today!

Categories

Recent Posts

Most Popular Posts