When you get an error from an API call, it can be tricky to tell if the error is coming from the API Manager (WSO2) or from the web service itself. (Sometimes we call that the backend web service since it is hidden behind the API Manager gateway.) Figuring out where the problem lies can help you talk to the right person faster. 

Brayden has written up a helpful document describing ways you can tell the difference

We're preparing to upgrade to version 2.1 of the WSO2 API Manager. Along with that upgrade, will be moving most of our WSO2 servers out to AWS. That move will not require any changes by API consumers and should not cause any downtime. It may invalidate some tokens earlier than the normal 60 minute timeframe. Make sure your code knows how to deal with an expired token and get a new one using your refresh token!

The purpose of this blog entry is to provide instruction and a working code example of interacting with BYU's Event Hub API through our API Manager powered by WSO2. I will cover the following: - Setup of a Node.js project - Invoking a managed API through BYU's API Manager - Code examples of an Event Generating Application (EGA) - Code examples of an Event Consuming Application (ECA)

Let's dive right in and start creating a project and code!

As part of our migration from SOASoft to our new API Manager we are also changing how client applications gain access to protected resources. SOASoft uses a home grown system called APIKey. Our new API Manager takes advantage of the OAuth 2.0 industry standard. The two authorization schemes share some similarities.

A little history...

Nearly ten years ago the Office of Information Technology (OIT) determined that our future applications should be driven by APIs based upon Web Services. Since then OIT has been heavily focused on providing APIs for use by OIT as well as campus consumers.

As part of our API initiative OIT implemented a number of technologies, including: