Handling I/O in Java

Handling input/output or I/O is one of the most common situations that programmers have to deal with. If you are writing a real world application, then you have to write a considerable amount of code to handle I/O regardless of the programming language or platform you’re going to use. Interestingly I/O plays a major role even in some of the simplest programs we can write. Even to write a standard ‘Hello World’ program in a language like Java or C, you need to know how to output characters to a console.

However, most developers often tend to ignore the importance and significance of I/O when writing code. Developers generally have an API level understanding of how to perform I/O operations using their main stream programming language. But they do not possess an in-depth understanding of how I/O works in the underlying system or how it can affect the performance and stability of the programs they write. Java developers in particular believe that knowing how to use the standard I/O API of Java is sufficient to write applications of good quality. Their lack of understanding on limitations and performance bottlenecks of the standard I/O API is astonishing. Most Java developers don’t have a firm grip on I/O coding best practices, third party I/O libraries available or relatively new concepts like NIO.

Last week I gave a talk at JAVA Colombo, the Sri Lankan JUG, trying to address some of the above issues. I started by giving a brief overview on I/O and I/O APIs in Java. I also introduced the NIO API and gave a short live demonstration of it comparing its performance to the standard I/O API of Java. Finally I discussed some of the best practices, patterns and anti-patterns related to writing I/O related code in Java. Full slide deck is now available on-line. Feel free to go through it send in your feedback.

Handling I/O in Java from Hiranya Jayathilaka

WSO2 API Manager Community Features: The Social Side of Things

Ability to build, nurture and sustain a healthy community of subscribers (API consumers) is one of the most prominent features expected from an API management solution. However the ability of the solution to support a rich and growing user base never stands on its own. In fact it's always contingent upon many functional, usability and social aspects of the underlying software. Techees such as myself, usually do a good job when identifying and implementing the functional side of things, but we suck at identifying other non-technical nitty-grittys. Therefore when designing the social aspects of WSO2 API Manager, we went through a ton of API management related literature. We wanted to make sure that the solution we build fits the customer needs and industry expectations well. We read many articles, blogs and case studies that highlighted the community aspects expected in API management solutions and how various software vendors have adopted those principles. We also talked to a number of customers who were either looking to enter the business of API management or were already struggling with some API management solution. As a result of this exercise we were able to identify a long list of functional and non-functional requirements that has a direct impact on the social aspects of API management solutions. I'm listing some of the most important ones here:

1. Ability to associate documentation and samples with APIs
2. Overall user friendliness of the API store
3. Ability to tag APIs and powerful search capabilities
4. Ability to rate APIs
5. Ability to provider feedback on APIs
6. Ability to track API usage by individual subscribers

If you go through the WSO2 API Manager Beta release you will notice how we have incorporated some of the above requirements into the product design.  If you login to API Publisher as a user who has the “Create” permission, then you are given a set of options to create documents for each API.

Again we have taken into consideration the fact that some API providers might already have tons of documentation, managed by an external CMS. For such users, it is not required to import all the available documents from the CMS into the WSO2 API Manager. They can continue to use the CMS for managing files and simply manage file references (URLs) through the API Manager.

Once the APIs are published to the API Store, subscribers and potential subscribers can browse through the available documents.

Subscribers are also given options to rate and comment on APIs.

API providers can associate one or more tags with each API.

Subscribers can use these tags to quickly jump into the APIs they are interested in.

In the monitoring front, WSO2 API Manager allows API providers to track how often individual subscribers have invoked the APIs.

In general, all the above features combine to give a pretty sleek and smooth API management experience as well as a strong notion of a user community. Feel free to browse through the other related features offered by WSO2 API Manager and see how the end-to-end story fits together. Personally I don't think we are 100% there yet in terms of the social aspects of the product, but I think we are off to a great start (anybody who tells you that their solution is 100% complete in social aspects is full of crap).

One very crucial feature that we are currently lacking in this area is alerting and notifications. Ideally the API Manager should notify the API subscribers about any changes that may occur in an API (for an example, an API becoming deprecated). On the other hand it should alert API providers when an API is not generating enough hype or subscriptions. We are already brainstorming about ways to add these missing pieces into the picture. Idea is to take them up as soon as the API Manager 1.0.0 goes GA so hopefully we can have an even more compelling community features story by the 1.1 release.  

API Life Cycles with WSO2 API Manager

One of the key API management challenges that we're trying to address in WSO2 API Manager is governing the API life cycle. Once you have developed, tested and published an API, you need to maintain it. Time to time you will roll out newer versions of the API into production with bug fixes, functional improvements and performance enhancements. When a new version is rolled out, you need to deprecate previously published versions thereby encouraging the subscribers to use the latest stable version of the API. However you will have to keep supporting the old versions for a period of time, thus providing existing subscribers some concession time to migrate to the latest version. But at some point you will completely take the old API versions off production and retire them from service. At a glance all this looks very simple and straightforward. But when you add the usual DevOps overhead into the picture, managing the API life cycle becomes one of the most complicated, long running tasks that you need deal with. If this long term procedure isn't tedious enough, there are many short term maintenance activities you have to do on APIs which are already in production. More often than not, you would want to temporarily block the active APIs so the system administrators can perform the required maintenance work on them. A well thought out API life cycle design should take these long term as well as short term requirements into consideration.

We at WSO2 gave this problem a long, hard thought and came up with the following schematic which illustrates the major life cycle states of a typical API.

If you download the beta release of WSO2 API Manager, you will see how we have incorporated the above model into the product design. Not only the product supports different life cycle states, it makes it absolutely simple to switch between different states. It's quite fascinating to see how API Publisher, API Store and API Gateway adjust to the changes in perfect synchronism as you take an API through its complete life cycle. In general these are the semantics that we have enforced for each life cycle state.

• Created – A new API has been created and awaiting moderation. It hasn't been published to the API Store yet and hence cannot be consumed.
• Published – API has been moderated and published to the API Store and is available to subscribers. Subscribers can use them in applications, generate keys against them and consume them.
• Deprecated – API has been marked for retirement in near future. New subscriptions are not allowed on the API, but the existing subscriptions and keys will continue to work. However the existing subscribers are highly advised to upgrade to the latest version of the API.
• Blocked – The API has been temporarily disabled for maintenance.
• Retired – The API has been permanently taken off service.

Lets try some of this stuff out and see for ourselves. Extract the downloaded WSO2 API Manager Beta pack, go into the “bin” directory and start the server up. Launch your web browser and enter the URL https://localhost:9443/publisher. Login to the portal using the default admin credentials (user: admin, pass: admin). Go ahead and create a new API. You can create the “FindTweets” API described in one of previous posts.

Note that the API is initially in the “CREATED” state. While in this state, the API is not visible in the API Store. Point your web browser to http://localhost:9763/store to confirm this. Now go back to the API Publisher portal and click on the “FindTweets” API. Select the “Life Cycle” tab which contains the necessary controls to change the API life cycle state. 

To start with put the API into the “PUBLISHED” state and click “Update”. Go to the API Store and refresh the page. The “FindTweets” API should now be visible there. 

You can login to the API Store, click on it and subscribe to the API using the “DefaultApplication”. When done your “My Subscriptions” page will look something like the following.

Go ahead and generate a production key too. Using this you can invoke the “FindTweets” API. Refer to my previous “Hello World” post if you're not sure how to invoke an API.

Now go back to API Publisher and change the API state to “BLOCKED”. If you immediately come back to the “My Subscriptions” page and refresh it, you will see that the “FindTweets” API is displayed as a “Blocked” API.

Any attempts to invoke this API will result in a HTTP 503 response.

Go back to the API Publisher and change the API state back to “PUBLISHED”. Try to invoke the API again, and you will notice that things are back to normal. Now in the API Publisher, go to the “Overview” tab of the “FindTweets” API and click on the “Copy” button.

Enter a new version number (eg: 2.0.0) to create a new version of the “FindTweets” API. The newly created version will be initially in the “CREATED” state and hence will not show up in API Store. However the API Publisher will list both versions of the API.

Now go to the “Life Cycle” tab of “FindTweets-2.0.0” and select the “PUBLISHED” state from the drop down. This time, since your API has some older versions, you will get some additional options to check.

Make sure all the provided options are checked. Checking the “Deprecate Old Versions” option ensures that all the older versions of the “FindTweets” API will be put into the “DEPRECATED” state as you roll out the new version into API Store. Checking the “Require Re-Subscription” option makes sure that existing subscribers will have to re-subscribe to the new version of the API in order to consume it. That is the keys generated against the old version of the API will not be forward compatible with the new version of the API. Having checked all the options, click the “Update” button to apply the changes. If you go back and check your “My Subscriptions” page you will notice that the API has been marked as “Deprecated”.

However, if you go to the API Store home page you will notice that the old version of “FindTweets” is no longer listed there. Only the latest published version is listed on this page.

Even if you somehow manage to access the “FindTweets-1.0.0” API details page on API Store (may be via the link available in “My Subscriptions” page), you will notice that you are no longer given any options for subscribing to the API. In other words, no new subscriptions are allowed on the deprecated APIs.

However if you try to invoke the old version of the API, using the previously obtained key, you will notice that it continues to function as usual.

And now finally, go back to the API Publisher and put the “FindTweets 1.0.0” API to the “RETIRED” state. Check the “My Subscriptions” page after the change.

Also try invoking the API with the old key. You will get a HTTP 404 back as the API has been undeployed from the system.

I hope this post gave you a brief introduction to how API governance and API life cycle management works in WSO2 API Manager. You can try various other options available in the product such as leaving the “Require Re-Subscription” option unchecked when publishing a new version of the API. See how that will automatically subscribe old subscribers to the new version of the API. See the extent to which API meta data is copied when creating a new version of the API using the “Copy” option. Send us your feedback to dev@wso2.org or architecture@wso2.org. 

WSO2 API Manager Permission Model: Controlling What Users Can Do

Most API management solutions segregate their user base into two main categories – API providers (creators) and API consumers (subscribers). Depending on the group to which a user belongs, the system determines what that person can and cannot do once he logs in. At WSO2, we were also thinking about supporting a similar notion of user groups in WSO2 API Manager from day one. However one thing we weren't very sure was whether a model with two user groups sufficient to address the real world business and technical needs in the field of API management. After a number of brain storming sessions, heated discussions and customer meetings we identified three main roles associated with API management.

1. API Creator – Designs, develops and creates APIs. Typically a techee, such as a developer.
2. API Publisher – Reviews the work done by the API creators and approves them to be published in the API Store. Doesn't necessarily have to be a techee. 
3. API Subscriber – Browses the API Store to discover APIs and subscribe to them. Typically a technical person, who's looking to develop an application using one or more APIs.

Once we had identified the user groups, the next challenge was incorporating them into our design in a flexible manner. We didn't want to tie our implementation to a specific set of user groups (roles) as that will make the end product quite rigid. Most users would want to simply plug their existing user store (a corporate LDAP or an Active Directory instance) into WSO2 API Manager, and they wouldn't want to introduce WSO2 API Manager specific user groups into their user store. Ideally they would like to designate some of their existing user groups as API creators, publishers and subscribers. And then we needed our solution to handle various edge cases without much of an effort. For an example, some companies would not want API creators and publishers to be different user groups. Some companies would prefer, API creators or publishers to also act as API subscribers so they can test the production APIs by directly consuming them. As you can see these edge cases can easily blur the distinction we have between different user groups.

So how do we introduce the notion of 3 user groups, while having the flexibility to reuse the roles defined elsewhere and combine multiple roles together when required? Thankfully, our WSO2 Carbon architecture has the perfect answer. Carbon gives us a powerful hierarchical permission model. So we introduced 3 Carbon permissions instead of 3 predefined user groups. 

1. Manage > API > Create
2. Manage > API > Publish
3. Manage > API > Subscribe

These permissions can be assigned to any user group as you see fit. If required, multiple permissions can be assigned to the same group too. For an example take an LDAP server which defines 3 different user groups – A,B and C. By properly assigning the above permissions to the respective groups, we can designate users in group-A as API creators, users in group-B as API publishers and users in group-C as subscribers. If we grant both Create and Publish permissions to group-A, users in that group will be able to both create and publish APIs.

Lets take an API Manager 1.0.0-Beta1 pack and try some of these stuff out. Download the binary distribution and extract it to install the product. Go to the "bin" directory of the installation and launch the wso2server.sh file (or wso2server.bat if you are on Windows) to start the server. Once the server has fully started up, start your web browser and go to the URL https://localhost:9443/carbon. You should get to the login page of WSO2 API Manager management console.

Login to the console using default admin credentials (user: admin, pass: admin). Select the 'Configure' tab and click on 'Users and Roles' from the menu to open the "User Management" page.

Lets start by adding a couple of new roles. Click on “Roles” which will list all the currently existing roles. WSO2 API Manager uses an embedded H2 database engine as the default user store. So if you were wondering where the user 'admin' and the default roles are stored, there's your answer. To use a different user store such as an external LDAP server, you need to configure the repository/conf/user-mgt.xml file accordingly.

You will notice 3 roles in the listing – admin, everyone and subscriber. The default "subscriber" role has the "Manage > API > Subscribe" permission. But don't get the wrong idea that the system is somehow tied into this role. The default "subscriber" role is created by the self sign up component of API Manager and it is fully configurable. I will get back to that later. For now click on the “Add New Role” option and start the role creation wizard. 

Enter the name “creator” as the role name and click “Next”.

From the permission tree select the “Configure > Login” and “Manage > API > Create” permissions and click “Next”. 

You will be asked to add some users to the newly created role. But for now simply click on “Finish” to save the changes and exit the wizard. You will now see the new “creator” permission also listed on the “Roles” page. Start the role creation wizard once more to add another role named “publisher”. Assign the “Configure > Login” and “Manage > API > Publish” permission to this role.

Now lets go ahead and create a couple of user accounts and add them to the newly created roles. Select “Users and Roles” option from the breadcrumbs to go back to the “User Management” page. Click on “Users”. 

This page should list all the user accounts that exist in the embedded user store. By default  the system has only one user account (admin) and so only that item will be listed. Click on “Add New User” to initiate the user creation wizard. 

Specify “alice” as the username and “alice123” as the password and click “Next”. 

Check the “creator” role from the list of available roles. The “everyone” role will be selected by default and you are not allowed by the system to uncheck that. Click on “Finish” to complete the wizard. Both “admin” and “alice” should now be listed on the “Users” page. Launch the user creation wizard once more to create another user named “bob”. Specify “bob123” as the password and make sure to add him to the “publisher” role. When finished, sign out from the management console.

So far we have created a couple of new roles and added some users to those roles. It's time to see how the API Manager utilizes the Carbon permission system. Point your web browser to https://localhost:9443/publisher to get to the API Publisher portal. Sign in using the username “alice” and password “alice123”. Since you are logging in with a user who has the “Manage > API > Create” permission, API creation options will be displayed to you.

Click on the “New API” button and create a new API (see my previous post on creating APIs). When you're finished click on the newly created API on the API Publisher home page. 

You will be shown options to edit the API and add documentation, but you will not see any options related to publishing the API. To be able to publish an API, we must login as a user who has the “Manage > API > Publish” permission. So sign out from the portal and login again as the user “bob”.

First thing to note is you don't get the “Create API” option on the main menu. So go ahead and just select the API previously created by the user “alice” from the home page.

While on this page, note that there are no options available for “bob” to edit the API. However you will see a “Life Cycle” tab which wasn't visible earlier when you were logged in as “alice”. Select this tab, and you should see the options to publish the API. Select the entry “PUBLISHED” from the “State” drop down and click “Update” to publish the API. The “Life Cycle History” section at the bottom of the page will get updated saying that “bob” has modified the API status. 

We are done with the API Publisher portal for the moment. Lets head out to API Store. Sign out from the API Publisher and point your browser to http://localhost:9763/store.  First of all try signing in as “alice” or “bob”. You will end up with an error message similar to the following.

Only those users with the “Subscribe” permission are allowed to login to the API Store. So we need to create a new user account with the “Manage > API > Subscribe” permission. We can use the self sign up feature of API Store to do that. Click on the “Sign-up” option at the top of the API Store portal. 

Create an account with the username “chris” and password “chris123”. When completed you should see a dialog box similar to the following.

Now go ahead and login as “chris”. This time the login attempt will be successful. The self sign up component, not only creates the user account, but also adds him to the “subscriber” role that we saw earlier in the management console. Since this role already has the “Manage > API > Subscribe” permission, self signed up users can always login to the API Store without any issues. Also try signing into the API Publisher portal as the user “chris”. You will get an error message similar to the following.

A word about the default “subscriber” role. This is not a role managed by the system, but rather something created by the self sign up component of the API Manager. In other words, this is the role to which all self signed up users will be assigned. You can change the name of this role by modifying the “SubscriberRoleName” parameter in the repository/conf/api-manager.xml file. If you are using an external user store, you can specify an existing role for this purpose too. If you don't want the API Manager to attempt to create this role in the system, set the “CreateSubscriberRole” parameter in api-manager.xml to “false”. If you're going to use an existing role as the subscriber role, make sure that role has the “Configure > Login” and “Manage > API > Subscribe” permissions so that the self signed up users can login to API Store and subscribe to APIs.

In order to see the effect of granting multiple API management permissions to the same role, you can use the default “admin” account. This user is in a role named “admin” which has all the permissions in the Carbon permission tree. Therefore this user can login to both API Store and API Publisher portals. On the API Publisher, he can see all the options related API creation, editing as well as publishing.

I believe you found our work on API Manager permission model interesting. Feel free to try different combinations of permissions and different types of user stores. Send us your feedback to dev@wso2.org or architecture@wso2.org. 

WSO2 API Manager Beta is Out

WSO2 API Manager 1.0.0-Beta1 is now up for grabs. You can download the binary distribution from here. This release comes with many bug fixes, functional enhancements and UI improvements. A full list of issues resolved for this beta release is available here.

One of the most significant changes done in this release is changing the URL contexts of the default API Publisher and API Store portals. API Publisher which was previously accessible on https://host:port/apiprovider has been moved to https://host:port/publisher. API Store which was previously available on http://host:port/apistore is now available on http://host:port/store.

We intend to release another beta version (1.0.0-Beta2) of API Manager before we make the final 1.0.0 release candidate available. In the meantime please try out our latest release and give us your valuable feedback on dev@wso2.org or architecture@wso2.org.

Hello World with WSO2 API Manager

A couple of months back, I took a little break from WSO2 ESB related work and focused my attention on WSO2 API Manager, one of our new and upcoming products. WSO2 API Manager is an enterprise grade, open source API management solution which solves a number of technical and business challenges faced by API providers as well as API consumers. It provides a simple, yet feature-rich platform for API providers to create and manage APIs. WSO2 API Manager is designed with software development and distribution best practices in mind which makes API governance, SLA management and monitoring absolutely trivial. For API consumers it provides a sleek, user friendly, App Store like experience where the consumers can browse through published APIs, subscribe to them, obtain API keys and provide feedback on APIs. 

In this blog post, I intend to walk you through some of the basic features of WSO2 API Manager. It’s written in the form of a short tutorial so you can actually try this out on your own. I’m going to start at the absolute beginning (downloading and installing the product), so hopefully you will be able to follow the material without any hiccups. I will provide more in-depth architectural details regarding WSO2 API Manager in a future post. 

Setting Up

Last week we announced the 1.0.0-alpha release of WSO2 API Manager. You can now download this version from our website. Start by downloading the binary distribution (wso2am-1.0.0-alpha.zip).The only prerequisite needed to run WSO2 API Manager is an installation of JDK 1.6 or higher. We generally recommend Oracle (Sun) JDK 1.6.0_23 but it should work fine on later versions of the JDK too including JDK 1.7. So far we have tested this release on Windows, Mac OS and several flavors of Linux. So if you have anyone of these operating systems with a JDK conforming to the above specs, you should be in a position to install and run WSO2 API Manager.

To install, simply extract the downloaded archive. Then open up a shell (or a command prompt if you’re on Windows) and go to the bin directory of the installation. You will find several shell scripts and batch files in this directory. To start the server up, just execute the wso2server.sh script (or wso2server.bat if you’re on Windows). You will start seeing a bunch of log statements on the console. Server start up may take several seconds. Wait until the server has fully booted up. When the server start up process is complete you will see the following log entry on the console.

[2012-07-07 01:30:31,154]  INFO - StartupFinalizerServiceComponent Server           :  WSO2 API Manager-1.0.0-ALPHA

[2012-07-07 01:30:31,155]  INFO - StartupFinalizerServiceComponent WSO2 Carbon started in 20 sec

[2012-07-07 01:30:31,415]  INFO - CarbonUIServiceComponent Mgt Console URL  : https://10.114.95.181:9443/carbon/

Creating APIs

Now we are all set to put WSO2 API Manager into action. Launch your web browser and navigate to https://localhost:9443/apiprovider. You should see the API Provider login screen as shown below.

Specify username and password as “admin” to sign in. You will be directed to the API Provider home page. This page usually lists all the APIs created. Since we are logging in for the first time and haven’t created any APIs so far, you won’t see anything here except for a welcome message and a “New API” button.

Click on the “New API” button which will take you to the “Add API” form. It’s time to create our first API. As our first example we are going to create an API named FindTweets which is based on the on-line search functionality provided by Twitter (See http://search.twitter.com). Consumers of our FindTweets API will be able to search for Tweets by providing a keyword as the input. Our API will accept both GET and POST requests and the output will be an Atom feed.

Enter following values into the respective fields of the Add API form. Optionally you can also download a nice looking Twitter icon and upload it as the API image. Leave other fields as they are.

• Name: FindTweets
• Context: /twitter
• Version: 1.0.0
• Endpoint: http://search.twitter.com
• Tiers: Gold, Silver, Bronze (select all 3 – this field supports multiple values)
• Business owner: Bruce Wayne
• Business owner e-mail: dark.knight@wayne-enterprises.com
• Technical owner: Peter Parker
• Technical owner e-mail: spidey@dailybugle.com

Once you have entered all the above values correctly, click the “Create” button to save the API configuration. You will be taken back to the API Provider home page where the new FindTweets API will be listed.

Now click on the FindTweet API. The API overview tab should get opened for you where you will be able to see a summary of the information you entered when creating the API.

Publishing APIs

When you create a new API, it's initially in the “CREATED” state. When an API is in this state, the consumers cannot see it in the API Store.  You can verify this by pointing your web browser to http://localhost:9763/apistore.  In order for the API to appear in the API Store, we should promote the API to the “PUBLISHED” state. To do this, go back to the API Provider home page and click on the FindTweets API. Select the “Life Cycle” tab, where you will see a drop down with different states the API can be in. 

Select the “PUBLISHED” state in the drop down and click the “Update” button to apply the state change. The API Provider will immediately start showing the API state as “PUBLISHED”. Now if you go back to the API Store at http://localhost:9763/apistore and refresh the page, you should be able to see the FindTweets API listed on the home page itself, before even signing into the portal.

Subscribing to APIs

Up to this point we have created a new API and successfully published it into the API Store. Now it's time to subscribe to our FindTweets API and start consuming it. Login to the API Store using the default administrator credentials (user: admin, pass: admin).  Click on the FindTweets API to go to the API overview page. There you should be able to see the “Subscribe” option. 

In order to subscribe to an API, you should first have an application in place. An application is a logical collection of APIs. Idea is that an API consumer (typically a developer) develops applications using one or more APIs. So the consumer can create a logical application in WSO2 API Manager, and subscribe to all the relevant APIs using that application. Afterwards the consumer can obtain a key against his/her application using which any API in that application can be invoked.

When you login to API Store for the first time, you are given an application named “DefaultApplication”. Select this entry in the “Applications” drop down. The “Tiers” drop down will list all the tiers you specified when creating the API. If you followed the instructions in this post to the letter, you should see Gold, Silver and Bronze listed here. Select the “Gold” tier and click on the “Subscribe” button. A pop up will appear asking whether you want to proceed to the “My Subscriptions” page. 

Select this option and go to the “My Subscriptions” page. There you should be able to see the “DefaultApplication” entry along with its subscription to the FindTweets API. 

Click the “Generate Production Key” option and then click the “Show Key” option to obtain a key for your application. Congratulations! You are now all set to consume the FindTweets API.

Testing the API

You can use any REST client to invoke the FindTweets API. For command line geeks like me, I can recommend Curl. If you're looking for some kind of a GUI tool, I can recommend Jmeter or SOAP UI. I recently came across a neat little Chrome extension named “Advanced REST Client” which is also a pretty awesome way to interact with the WSO2 API Manager.

If you're using Curl, the following command should invoke the FindTweets API and get you a result.

curl -v -H “Authorization: Bearer xxxxx” http://localhost:8280/twitter/1.0.0/search.atom?q=wso2

Replace the 'xxxx' with the application key you obtained earlier. If you pass the right key, the API Manager will route the call to search.twitter.com and get you an Atom feed consisting of all the recent Tweets tagged with the keyword 'wso2'.

Here's how you can try the same using the Advanced REST Client for Chrome.

Note how we are passing the application key in the Authorization header of the message, prefixed by the string “Bearer”. This is because WSO2 API Manager enforces OAuth security on all the published APIs. Any consumer that talks to the API Manager should send their credential (application key) as per the OAuth bearer token profile. If you don't send an application key or send a wrong key, you will receive a 401 Unauthorized response in return.

Also remember that we subscribed to the FindTweets API using the “Gold” tier. This tier only allows 20 requests per minute. So if you keep sending requests fast, after 20 requests the throttling policy will kick in and you will start receiving 503 responses.

So there you have it; a simple 'Hello World' scenario with WSO2 API Manager. I'm sure at this point you're itching to try out more use cases with this product. Here are a few things you can try out:

1. Add more users with different permissions and see how the user experience changes according to the available permissions
2. BAM integration for monitoring APIs
3. Adding API documents
4. Rating and commenting on APIs
5. Deprecating and blocking APIs

Expect a few more blog posts from me covering the above topics. If you want to see a recording of the scenario I have described above, take a look at this webinar recording. Last but not least, go through this blog post by Kin Lane, the famous API evangelist.