The WSO2 API Manager comprises the following main components:
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.
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.
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 which 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 for 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 an 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, refer to section Monitoring using WSO2 BAM.
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.
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
MessageContextvariables as appropriate.
APIThrottleHandler: Throttles requests based on the throttling policy specified by the
policyKeyproperty. 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 . See Monitoring using WSO2 BAM for more information.
APIMgtGoogleAnalyticsTrackingHandler: Publishes events to Google Analytics. This handler only comes into effect if Google analytics tracking is enabled. See for more information.
APIManagerExtensionHandler: Extends the mediation flow of messages passing through the API Gateway. See Adding a Mediation Extension 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 login, it directly forwards the calls to Key Manager server. You must pass username, password, consumer key and consumer secret key with it to register their applications. 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 mode is using Thrift but you can change the
WSClient in api-manager.xml file.
The following diagram depicts the collaboration of these main components with an easily-integrable monitoring and statistics component.