Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


Skip to end of metadata

Go to start of metadata

This guide will help you get started consuming APIs in WS02.

Step-by-step guide

  1. Create a WSO2 Application
    1. Follow the guide for creating a WSO2 Application here.
    2. An Application will represent your implementation of consuming the API. This could be in the form of a front-end Single Page Application (SPA), a separate service that needs data from a set of APIs, or just a curl command.
  2. Subscribe Application to desired API
    1. Follow the guide to subscribe to a WSO2 managed API here.
    2. A WSO2 Application can have multiple subscriptions. The WSO2 Application should subscribe to all the APIs needed for the implementation application (SPA, etc.) to function. Having all the needed APIs subscribed under one WSO2 Application will simplify the use of the OAuth access token described below.
  3. Generate Application keys
    1. A WSO2 Application may have two sets of credentials (or keys). These keys are used to retrieve an access token, which your code will use to make HTTP requests to your subscribed API. (In WS02, the "TryIt" feature performs this kind of request.)
    2. Follow the last step in the guide, "Subscribing to an API in the Store" to generate your keys. You may generate both Production and/or Sandbox keys.
    3. The Production keys are associated with the Production endpoint of a subscribed API, and the Sandbox keys are associated with the Sandbox endpoint of a subscribed API. The following is a screenshot example of the Production/Sandbox endpoint configuration when an API is configured in WSO2:
    4. Notice that the Production Endpoint should be different than the Sandbox Endpoint. The Production Endpoint represents the service that is production-ready, whereas the Sandbox Endpoint represents a staging service for testing and verification, and/or development.
    5. Once you have generated your Production and/or Sandbox keys, you will use them to access data from an API. The two examples below each show a different method of how to do this.
  4. Use an Access Token to make a curl request to your subscribed API

    1. You can now make a valid request to your subscribed API by taking the "Access Token" as shown above and using it in an HTTP request.
    2. The "Access Token" represents your authorization to access the API. WSO2 API Manager would return a 403 HTTP response code if you did not provide an access token or if the access token was not a valid token generated from your WSO2 Application keys.
    3. Add an "Authorization" header in your request with the value: "Bearer <Access Token>" (except replacing <Access Token> with an actual value).
    4. Here is an example curl request: 
      curl --header "Authorization: Bearer 271ae9ef62624272e718ede3dfd48eee" https://api.byu.edu:443/domains/tutorials/cars
    5. There you have it! You should see the expected content from your subscribed API.
  5. Use the "TryIt" feature to make a request to your subscribed API
    1. Instead of performing a curl request, you can access your subscribed API via the "TryIt" feature found on the API console within the API store
    2. A step-by-step guide to using the "TryIt" feature can be found here.

 

Please noteOAuth 2.0 specifies four separate authorization grant types: Authorization Code, Implicit Grant, Resource Owner, and Client Credentials. BYU OIT deals primarily with the Authorization Code and Client Credentials grant types. The Authorization Code grant type is used in conjunction with authenticating users. The Client Credentials grant type, on the other hand, is used for service-to-service API calls which do not involve an authenticated user. The procedure of subscribing to and calling an API is different for each grant type. This article explains how to call an API using the Client Credentials grant type only.

  • No labels