Architecture

The WSO2 API Manager comprises the following main components:

API Publisher

Provides an end-user, collaborative Web interface for API providers to publish APIs, share documentation, provision API keys, and gather feedback on API features, quality and usage. The API Publisher is powered by Jaggery, WSO2 Governance Registry and WSO2 Identity Server products.

For more information on API Publisher and its functionality, refer to sections  API Developer Guide.

API Store

Provides an end-user, collaborative Web interface for consumers to self-register, discover API functionality, subscribe to APIs, evaluate them and interact with API publishers. The API Store is powered by Jaggery, WSO2 Governance Registry and WSO2 Identity Server products.

For more information on the API Store and its functionality, refer to section  Application Developer Guide.  

API Gateway

A runtime, back-end component developed using the WSO2 ESB, which is proven for its performance capability. API Gateway secures, protects, manages, and scales API calls. The API gateway 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. We use a set of handlers for security validation and throttling purposes in the API Gateway. Upon validation, it passes Web service calls to the actual back-end. If the service call is a token request call, API Gateway passes it directly to the API Key Manager Server to handle it.

The API Gateway is accessible through the URL: https://localhost:9443/carbon once the API Manager server is up and running.

You can integrate a monitoring and statistics component to the API Manager without any additional configuration effort. This monitoring component integrates with the WSO2 Business Activity Monitor, which can be deployed separately to analyze events generated by the API manager. For more information, see Publishing API Runtime Statistics.

API Handlers

When an API is published, a file with its synapse configuration is created on the API Gateway. The synapse configuration of each API has a set of handlers. Each of these handlers is executed on the APIs in the order they appear in the configuration.

You can find a set of default handlers in any API Synapse definition as shown below.

<handlers>
   <handler class="org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler"/>
   <handler class="org.wso2.carbon.apimgt.gateway.handlers.throttling.APIThrottleHandler">
        <property name="id" value="A"/>
        <property name="policyKey" value="gov:/apimgt/applicationdata/tiers.xml"/>
   </handler>
   <handler class="org.wso2.carbon.apimgt.usage.publisher.APIMgtUsageHandler"/>
   <handler class="org.wso2.carbon.apimgt.usage.publisher.APIMgtGoogleAnalyticsTrackingHandler"/>
   <handler class="org.wso2.carbon.apimgt.gateway.handlers.ext.APIManagerExtensionHandler"/>
</handlers>

Let's see what each handler does:

• APIAuthenticationHandler : Validates the OAuth2 bearer token used to invoke the API. It also determines whether the token is of type Production or Sandbox and sets MessageContext variables as appropriate. To extend the default authentication handler, see Writing Custom Handlers.
• APIThrottleHandler : Throttles requests based on the throttling policy specified by the policyKey property. Throttling is applied both at the application level as well as subscription level.
• APIMgtUsageHandler : Publishes events to BAM for collection and analysis of statistics. This handler only comes to effect if API usage tracking is enabled. See Publishing API Runtime Statistics for more information.
• APIMgtGoogleAnalyticsTrackingHandler : Publishes events to Google Analytics. This handler only comes into effect if Google analytics tracking is enabled. See Integrating with Google Analytics for more information.
• APIManagerExtensionHandler : Extends the mediation flow of messages passing through the API Gateway. See Adding Mediation Extensions for more information.

API Key Manager

The API Key Manager component handles all security and key-related operations. When API Gateway receives API calls, it contacts the API Key Manager service to verify the validity of tokens and do security checks. When API Gateway receives calls to log in, it directly forwards the calls to Key Manager server. You must pass username, password, consumer key and consumer secret key with it to register. All tokens used for validation are based on OAuth 2.0.0 protocol. Secure authorization of APIs is provided by the OAuth 2.0 standard for key management. The API Gateway supports API authentication with OAuth 2.0, and enables IT organizations to enforce rate limits and throttling policies.

When the API Gateway receives API invocation calls, it similarly contacts the API Key Manager service for verification. This verification call happens every time the Gateway receives an API invocation call if caching is not enabled at the Gateway level. For this verification, the Gateway passes access token, API, API version to the Key Manager.

Communication between API Gateway and Key Manager happens in either of the following ways:  

• Through a Web service call
• Through a Thrift call

The default communication protocol of Key Manager is Thrift, which is an RPC framework used to develop scalable, cross-language services. Thrift is much faster than SOAP over HTTP communication.

If your setup has a cluster of multiple Key Manager nodes that are fronted by a WSO2 ELB instance for load balancing, change the key management protocol from Thrift to WSClient using the <KeyValidatorClientType> element in <APIM_HOME>/repository/conf/api-manager.xml file. Thrift uses TCP load balancing and the ELB does not support it.

The following diagram depicts the collaboration of these main components with an easily-integrable monitoring and statistics component.