A runtime, backend component (an API proxy) developed using WSO2 ESB. API Gateway secures, protects, manages, and scales API calls. It intercepts API requests, applies policies such as throttling and security using handlers and manages API statistics. Upon validation of a policy, the Gateway passes Web service calls to the actual backend. If the service call is a token request, the Gateway passes it directly to the Key ManagerValidator.
When the API Manager is running, you can access the Gateway using the URL You integrate a monitoring and statistics component to the API Manager without any additional configuration effort. This monitoring component integrates with WSO2 Business Activity Monitor, which can be deployed separately to analyze events. For more information, see Publishing API Runtime Statistics.
Although the API Gateway contains ESB features, it is recommended not to use it for ESB-specific tasks. Use it only for Gateway functionality related to API invocations. For example, if you want to call external services like SAP, use a separate ESB cluster for that.
Handles all security and key-related operations. The Gateway connects with the key manager Key Validator to check the validity of OAuth tokens when APIs are invoked, subscriptions, API invocations etc. The key manager Key Validator also provides a token API to generate OAuth tokens that can be accessed via the Gateway. All tokens used for validation are based on the 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 Gateway receives API invocation calls, it similarly contacts the Key Manager Validator service for verification. If is not enabled at the Gateway level, this verification call happens every time the Gateway receives an API invocation call. For For this verification, the Gateway passes an access token, the API, API version to the Key ManagerValidator. Communication between the API Gateway and the Key Manager Validator happens in either of the following ways:
- Through a Web service call
- Through a Thrift call (Thrift is the default communication protocol and is much faster than SOAP over HTTP)
If your setup has a cluster of multiple Key Manager Validator nodes that are fronted by a load balancer that does not support Thrift, change the key management protocol from Thrift to WSClient using the
<KeyValidatorClientType> element in . Thrift uses TCP load balancing.
When an API is created, a file with its synapse configuration is added to the API Gateway. You can find it in the
<APIM_HOME>/repository/deployment/server/synapse-configs/default/api folder. It has a set of handlers, each of which is executed on the APIs in the same order they appear in the configuration. You find the default handlers in any API's Synapse definition
If you are using a distributed API Manager setup (i.e., Publisher, Store, Gateway and Key Manager Validator components are running on separate JVMs), edit the template in the Publisher node.
For information on configuring caching response messages and caching API calls at the Gateway and Key Manager Validator server, see Configuring Caching.