This documentation is for WSO2 API Manager 1.7.0 View documentation for the latest release.
Quick Start Guide - API Manager 1.7.0 - WSO2 Documentation

All docs This doc
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

« Previous Version 68 Next »

WSO2 API Manager is a complete solution for publishing APIs, creating and managing a developer community and for routing API traffic in a scalable manner. It leverages the integration, security and governance components from the WSO2 Enterprise Service Bus, WSO2 Identity Server, and WSO2 Governance Registry. In addition, as it is powered by the WSO2 Business Activity Monitor (BAM), the WSO2 API Manager is ready for massively scalable deployment immediately.

This guide walks you thorough the main usecases of the API Manager:

Introduction to basic concepts

Let's take a look at the basic concepts that you need to know before using the API Manager.

Components

The API manager comprises the following components:

  • API Gateway : Secures, protects, manages, and scales API calls. It is a simple API proxy that intercepts API requests and applies policies such as throttling and security checks. It is also instrumental in gathering API usage statistics. The Web interface can be accessed via https://<Server Host>:9443/carbon.
  • API Key Manager : Handles all security and key-related operations. API gateway connects with the key manager to check the validity of OAuth tokens when APIs are invoked . Key Manager also provides a token API to generate Oauth tokens that can be accessed via the Gateway.
  • API Publisher : Enables API providers to publish APIs, share documentation, provision API keys, and gather feedback on API features, quality and usage. The Web interface can be accessed via https://<Server Host>:9443/publisher.
  • API Store : Enables API consumers to self register, discover API functionality, subscribe to APIs, evaluate them and interact with API publishers. The Web interface can be accessed via https://<Server Host>:9443/store.
  • Additionally, statistics are provided by the monitoring component, which integrates with WSO2 BAM.

Users and roles

The API manager offers three distinct community roles that are applicable to most enterprises:

  • Creator : a creator is a person in a technical role who understands the technical aspects of the API (interfaces, documentation, versions, how it is exposed by API Gateway) and uses the API publisher to provision APIs into the API store. The creator uses the API Store to consult ratings and feedback provided by API users. Creator can add APIs to the store but cannot manage their lifecycle (i.e., make them visible to the outside world).
  • Publisher : a publisher manages a set of APIs across the enterprise or business unit and controls the API lifecycle and monetization aspects. The publisher is also interested in usage patterns for APIs and as such has access to all API statistics.
  • Consumer : a consumer uses the API store to discover APIs, see the documentation and forums and rate/comment on the APIs. S/he subscribes to APIs to obtain API keys.
API lifecycle

An API is the published interface, while the service is the implementation running in the backend. APIs have their own lifecycles that are independent to the backend services they rely on. This lifecycle is exposed in the API publisher Web interface and is managed by the API publisher role.

The following stages are available in the default API life cycle:

  • CREATED : API metadata is added to the API Store, but it is not visible to subscribers yet, nor deployed to the API gateway
  • PROTOTYPED : API is deployed and published in the API Store as a prototype. A prototyped API is usually a mock implementation made public in order to get feedback from users about its usability. Users cannot subscribe to a prototyped API. They can only try out its functionality.
  • PUBLISHED : API is visible in the API Store and available for subscription.
  • DEPRECATED : API is still deployed into the API Gateway (i.e., available at runtime to existing users) but not visible to subscribers. An API can automatically be deprecated when a new version is published.
  • RETIRED : API is unpublished from the API gateway and deleted from the store
  • BLOCKED : Access is temporarily blocked. Runtime calls are blocked and the API is not shown in the API Store anymore.

You can manage the API and service lifecycles in the same governance registry/repository and automatically link them. This feature is available in WSO2 Governance Registry (version 4.5 onwards).

Applications

An application is primarily used to decouple the consumer from the APIs. It allows you to :

  • Generate and use a single key for multiple APIs
  • Subscribe multiple times to a single API with different SLA levels

You create an application to subscribe to an API. The API Manager comes with a default application and you can also create as many applications as you like.

Throttling tiers

Throttling tiers are associated to an API at subscription time. They define the throttling limits enforced by the API gateway. E.g., 10 TPS (transactions per second). You define the list of tiers that are available for a given API at the publisher level. The API Manager comes with three predefined tiers (Gold/Silver/Bronze) and a special tier called Unlimited, which can be disabled by editing the <TierManagement>element of <PRODUCT_HOME>/repository/conf/api-manager.xml file. To edit existing tiers or create your own tiers, see Adding New Throttling Tiers.

API keys

The API Manager supports two scenarios for authentication:

  1. An access token is used to identify and authenticate a whole application
  2. An access token is used to identify the final user of an application (for example, the final user of a mobile application deployed on many different devices)
Application access token

Application access tokens are generated by the API consumer and must be passed in the incoming API requests. The API Manager uses OAuth2 standard to provide key management. The API key is a simple string that you pass to an HTTP header (e.g., "Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a") and it works equally well for SOAP and REST calls.

Application access tokens are generated at the application level and valid for all APIs that are associated to the application. These tokens have a fixed expiration time, which is set to 60 minutes by default. You can change this to a longer time, even for several weeks. Consumers can re-generate the access token directly from the API Store Web interface. To change the default expiration time, you open <APIM_HOME>/repository/conf/identity.xml file and change the value for element <ApplicationAccessTokenDefaultValidityPeriod>. You set a negative value to <ApplicationAccessTokenDefaultValidityPeriod> element to never expire the application access token.

Application user access token

You can generate access tokens on demand using the token API. In case a token expires, you use the token API to refresh it.

Application user access tokens have a fixed expiration time, which is 60 minutes by default. You can update it to a longer time, such as several weeks, by editing the <AccessTokenDefaultValidityPeriod> element in <APIM_HOME>/repository/conf/identity.xml file.

The token API takes the following parameters to generate the access token:

  • Grant Type
  • Username
  • Password
  • Scope

To generate a new access token, you issue a token API call with the above parameters where grant_type=password. The Token API then returns two tokens: an access token and a refresh token. The access token can then be stored in a session on the client side (the application itself does not need to manage users and passwords). On the API Gateway side, the access token is validated for each API call. When the token expires, you refresh the token by issuing a token API call with the above parameters where grant_type=refresh_token and passing the refresh token as a parameter.

Starting the API Manager

  1. Download WSO2 API Manager from http://wso2.com/products/api-manager/.
  2. Install Oracle Java SE Development Kit (JDK) version 1.6.24 or later or 1.7.*.
  3. Set the JAVA_HOME environment variable.
  4. Using the command line, go to <Installation directory>/bin and execute wso2server.bat (for Windows) or wso2server.sh (for Linux).
  5. Wait until you see the message "WSO2 Carbon started in 'n' seconds."

    It indicates that the server started successfully. To stop the API Manager, simply hit Ctrl-C in the command window.

Creating users and roles

In section Users and roles , we introduced you to a set of users that are commonly found in many enterprises. To create these users in the API Manager, you log in to the management console as an administration user (credentials: admin/admin). The admin use can play the creator, publisher and subscriber roles described earlier. In this section, we explain how to set up these users or custom users and roles.

  1. Log in to the management console user interface ( https://<hostname>:9443/carbon ) of the API Manager using admin/admin credentials.

  2. Select the Users and Roles menu under the Configure menu.
  3. Click Add New Role and provide creator as the role name.
  4. Click Next.
  5. Select the following permissions from the list that opens and click Finish.
    • Login
    • Manage > API > Create
    • Manage > Resources > Govern and all underlying permissions
  6. Similarly, create the publisher role with the following permissions.

    • Login
    • Manage > API > Publish
  7. You can now create users for each of those roles. To do so, click the Users and Roles menu under the Configure menu.
  8. Click Users.
  9. Click Add New User, provide the username/password and click Next.
  10. Select the role you want to assign to the user (e.g., creator, publisher or subscriber) and click Finish. Given below is a list of usernames and the roles we assign to them in this guide.

    UsernameRole
    apicreatorcreator
    apipublisherpublisher

    Repeat the steps to create at least one user for all roles.

Creating an API

An API creator uses the API provider Web application to create and publish APIs into the API Store. In this section, we explain how to create an API and attach documentation to it.

In this guide, we work with a service exposed by the Cdyne services provider (www.wdyne.com). We use their phone validation service, which has SOAP and REST interfaces and is documented using a WSDL file. This service is documented at : http://wiki.cdyne.com/index.php/Phone_Verification.

Let's create this API and add it to the API Store.

  1. Open the API Publisher ( https://<hostname>:9443/publisher ) and log in as apicreator.
  2. Click the Add link and provide the information given in the table below.

    FieldValueDescription
    Name
    PhoneVerification
    Name of API as you want it to appear in the API
    store
    Context
    /phoneverify
    URI context path that is used by to API consumers
    Version1.0.0API version (in the form of version.major.minor)
  3. Click Implement.

  4. It asks you to create a resource with wildcard characters (/*). Click Yes.
  5. Note that a resource by the name default gets created as follows.
  6. Click Implement again to go to the Implement tab and provide the following information.

    FieldValueDescription
    Implementation methodBackend endpointIf you have a real backend implementation to your API, select that option. Else, you can specify implementation in-line. The latter approach is usually used in mock-up implementation for prototyped APIs.
    Endpoint typeHTTP endpoint 
    Production endpointhttp://ws.cdyne.com/phoneverify/phoneverify.asmx 
    Endpoint security schemeNon Secured

    If the endpoint is secured, user is asked for credentials of the backend service.

    WSDLURL:
    URL of WSDL file (describing API interface)
  7. Click Manage to go to the Manage tab and provide the following information.

    FieldValueDescription
    Tier AvailabilityBronze/Gold/Silver/UnlimitedThe API can be available at different level of service; you can select multiple entries from the list. At subscription time, the consumer chooses which tier they are interested in.
    TransportsHTTP/HTTPS 
    Edit resourcesEdit the scope, auth type and throttling tiers of the URL pattern added in design stageAuth type: Resource level authentication along HTTP verbs. Can be one of the following:
    • None : Can access the API resource without any access tokens
    • Application: Application access token is required to access the API resource
    • Application User: User access token is required to access the API resource

    Also see Managing Throttling Tiers.

       

    API Resources

    An API is made up of one or more resources. Each resource handles a particular type of request and is analogous to a method (function) in a larger API. API resources accept following optional attributes:

    • verbs : Specifies the HTTP verbs a particular resource accepts. Allowed values are GET, POST, PUT, DELETE. Multiple values can be specified.  
    •   uri-template : A URI template as defined in http://tools.ietf.org/html/rfc6570. ( e.g., /phoneverify/<phoneNumber> )  
    •   url-mapping : A URL mapping defined as per the servlet specification (extension mappings, path mappings and exact mappings)  
    • Auth-Type: Specifies the Resource level authentication along HTTP verbs. Auth-type can be None, Application or Application User.  
      • None : Can access the particular API resource without any access tokens
      • Application: Application access token required to access the API resource
      • Application User: User access token required to access the API resource

Adding API documentation

  1. After creating the API, click on its icon to open its details. Select the Docs tab.

  2. Click Add New Document link.

    Documentation can be provided inline, via a URL or as a file. For inline documentation, you can edit the content directly from the API publisher interface. You get several documents types:
    • Swagger documents
    • How To
    • Samples and SDK
    • Public forum / Support forum (external link only)
    • API message formats
    • Other
  3. Select the How To type, a name for the document and a short description, which will appear in the API Store. Select inline or provide a URL.
  4. Click Add Document.
  5. Once the document is added, click Edit Content link, which opens an embedded editor to edit the document contents.

Adding interactive documentation using Swagger

The API Manager provides facility to add interactive documentation support through the integration of Swagger. Swagger is a specification and a complete framework implementation for describing, producing, consuming, and visualizing RESTful Web services. In Swagger, when APIs are described in simple static JSON representation, they can be loaded through the Swagger UI, which in turn provides the interactive documentation.

When an API is created, the JSON representation of that API is automatically generated and saved into the registry as API definition. This definition describes the API with the information provided at the API creation level. You can customize the automatically generated API definition by going to the Doc tab of the PhoneVerification API in the API Publisher. You can modify the paths, parameters, descriptions etc. by editing the JSON representation of API definition. For more information, see Adding Documentation Using Swagger.

Versioning the API

Next, we will create a new version of this API.

  1. Log in to the API Publisher as apicreator if you are not logged in already.
  2. Click on the PhoneVerification API and then the Copy button that appears in its Overview tab.
  3. Specify a new version number (of the version.major.minor format) and click Done.

A new version of the API is created. It is a duplication of all the contents of the original API, including the documentation. The API is now ready to be published. This is done by a user in the publisher role.

Publishing the API

  1. Log in to the API Publisher Web application as apipublisher.
  2. Click on the PhoneVerification API. Note that you can now see a tab as API Lifecycle in the API Publisher UI.
  3. Go to the Lifecycle tab and select the state as PUBLISHED from the drop-down list.

    Propagate Changes to API Gateway

    Used to define an API proxy in the API Gateway runtime component, allowing the API to be exposed to the consumers via the API Gateway. If this option is left unselected, the API metadata will not change and you will have to manually configure the API Gateway according to the information published in the API Store.

    Deprecate Old Versions

    If selected, any prior versions of the API will be set to the DEPRECATED state automatically.

    Require Re-Subscription

    Invalidates current user subscriptions, forcing users to subscribe again.

The API is now published and visible to consumers in the API store.

Subscribing to the API

You subscribe to APIs using the API Store Web application.

  1. Open the API Store ( https://<hostname>:9443/store ) using your browser and search for the API you created earlier.

    You can browse the API Store, search APIs, check documentation without logging in. However, to comment, rate and subscribe to APIs, you must sign up and log in. For example,
  2. Self sign up to the API Store using the Sign-up link in the stop, right-hand corner of the screen.
  3. Log in to the API Store and click the API you created (PhoneVerification).
  4. Note the subscription option that you now see in the right hand side of the UI.

    You need an application to subscribe to and consume APIs. Requests made from this application are regulated by throttling tiers that you select. You can use the Default application, which comes by default with the API Manager. Select Bronze as the tier and click  Subscribe.

    Alternatively, you can also create your own application by selecting New application from the drop-down list here go by going to the My Applications tab in the top menu bar.
  5. Once the subscription is successful, go to My Subscriptions page.
  6. In the My Subscriptions page, click the Generate buttons to generate production and sandbox access tokens and consumer key/secret pairs for the API. For more information on access tokens, see Working with Access Tokens.
You are now successfully subscribed to the API and are ready to start using it.

Invoking the API

To test the API, you can use the integrated REST client or any other client application such as curl.

  1. Open the API Store (https: //<YourHostName>:9443/store) in a Web browser.
  2. The REST Client menu appears under the Tools menu in the top, right-hand corner of the screen. Clicking it opens the REST client.
  3. Provide the necessary parameters to call the API. For example, shown below is how to invoke a Google API using the REST Client.
API URL

The API URL takes the form http://host:8280/ <context>/<version>/<back end service requirements included as parameters> . For example, http://localhost:8280/stock/1.0.0 .

Header

In the above request, the application key generated at the time a user subscribes to an API is passed with the authorization header, which is 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.

The number of API calls you can make depends on the throttling tier applied to the API. For example, if a Bronze tier is applied, the number of API calls is limited to 1 per minute. Another attempt to call the API during that time results in a throttling error.

Monitoring APIs and viewing statistics

Both the API publisher and store provide several statistical dashboards. Some of them are as follows:

  • Number of subscriptions per API (across all versions of an API)
  • Number of API calls being made per API (across all versions of an API)
  • The subscribers who did the last 10 API invocations and the APIs/versions they invoked
  • Usage of an API and from which resource path (per API version)

  • Number of times a user has accessed an API
  • The number of API invocations that failed to reach the endpoint per API per user
  • API usage per application
  • Users who make the most API invocations, per application
  • API usage from resource path, per application

You view these statistics through the Statistics menu in API Publisher (as shown below).

Similarly, the API Store also has a Statistics menu.

Also see Viewing API Statistics.

Initially, statistics pages show sample graphs for your reference. To see real runtime statistics specific to your server, you configure WSO2 Business Activity Monitor and trigger some events to generate statistics. For more information, see Publishing API Runtime Statistics.

This concludes the API Manager quick start. You have set up the API Manager and taken a look at its common usecases. For more advanced usecases, please see the User Guide and the Admin Guide of the API Manager documentation.

  • No labels