This documentation is for WSO2 API Manager 1.8.0 View documentation for the latest release.
Key Concepts - API Manager 1.8.0 - WSO2 Documentation
||
Skip to end of metadata
Go to start of metadata

Let's take a look at some concepts and terminology that you need to know in order to follow the use cases.

API Manager components

A component is made up of one or more OSGi bundles. A bundle is the modularization unit in OSGi, similar to a JAR file in Java. The component-based architecture of all WSO2 products gives developers flexibility to remove or add features with minimum dependencies.

The API Manager comprises the following high-level components:

ComponentDescription
API PublisherProvides 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. For API Publisher use cases, see API Developer Tutorials.
API StoreProvides an end-user, collaborative Web interface for API consumers to self register, discover API functionality, subscribe to APIs, evaluate them and interact with API publishers. For API Store use cases, see Application Developer Tutorials.
API Gateway

A runtime, back end 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 back end. If the service call is a token request, the Gateway passes it directly to the Key Manager. 

When the API Manager is running, you can access the Gateway using the URL https://localhost:9443/carbon. 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.

Key ManagerHandles all security and key-related operations. The Gateway connects with the key manager to check the validity of OAuth tokens when APIs are invoked. The key manager also provides a token API to generate OAuth tokens that can be accessed via the Gateway. 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 Gateway receives API invocation calls, it similarly contacts the Key Manager service for verification. If caching is not enabled at the Gateway level, this verification call happens every time the Gateway receives an API invocation call . 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 (Thrift is the default communication protocol and is much faster than SOAP over HTTP)

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.

 Handlers

When an API is created, a file with its synapse configuration is added to the API Gateway. You can find 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 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.

StatisticsAdditionally, statistics are provided by the monitoring component, which integrates with WSO2 BAM.

The components are depicted in the diagram below:


Users and roles

The API Manager offers four distinct community roles that are applicable to most enterprises:

  • Admin: The API management provider who hosts and manages the  API Gateway . S/he is responsible for creating user roles in the system, assign them roles, managing databases, security etc. The Admin role is available by default with credentials admin/admin.
  • Creator: a creator is a person in a technical role who understands the technical aspects of the API (interfaces, documentation, versions etc.) 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.
  • Publisher : a publisher manages a set of APIs across the enterprise or business unit and controls the API lifecycle, subscriptions and monetization aspects. The publisher is also interested in usage patterns for APIs and has access to all API statistics.
  • Subscriber : a subscriber uses the API store to discover APIs, read the documentation and forums, rate/comment on the APIs, subscribes to APIs, obtain access tokens and invoke the APIs.

Tip: See Managing Users and Roles for more information.


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 lifecycle:

  • CREATED: API metadata is added to the API Store, but it is not deployed in the API gateway and therefore, is not visible to subscribers in the API Store.
  • PROTOTYPED: the 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 about its usability. Users can invoke the API without a subscription.
  • PUBLISHED: The API is visible in the API Store and available for subscription.
  • DEPRECATED: When an API is deprecated, new subscriptions are disabled. But the API is still deployed in the Gateway and is available at runtime to existing subscribers. Existing subscribers can continue to use it as usual until the API is retired.
  • RETIRED: The API is unpublished from the API gateway and deleted from the store.
  • BLOCKED: Access to the API is temporarily blocked. Runtime calls are blocked and the API is not shown in the API Store anymore.

Applications

An application is a logical collection of APIs. 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 subscribe to APIs through an application. Applications are available at different SLA levels, and have application-level throttling tiers engaged in them. A throttling tier determines the maximum number of calls you can make to an API during a given period of time.

The API Manager comes with a pre-created, default application, which allows unlimited access by default. You can also create your own applications.


Access tokens

An access token is a simple string that is passed as an HTTP header of a request. For example, "Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a." Access tokens authenticate API users and applications, and ensure better security (e.g., prevent DoS attacks). If a token that is passed with a request is invalid, the request is discarded in the first stage of processing. Access tokens work equally well for SOAP and REST calls.

There are two types of access tokens:

User access tokens

Tokens to authenticate the final user of an API. User access tokens allow you to invoke an API even from a third-party application like a mobile app. You generate/renew a user access token by calling the Login API through a REST client. For more information, see Token API.

Application access tokens

Tokens to authenticate an application, which is a logical collection of APIs. You to access all APIs associated with an application using a single token, and also subscribe multiple times to a single API with different SLA levels. Application access tokens leverage OAuth2 to provide simple key management.

The steps below describe how to generate/renew application access tokens:

  1. Log in to the API Store.
  2. Click the My Subscriptions menu, select the application from the drop-down list and click the Generate or Regenerate buttons to create and renew access tokens.

    Whenever an API call happens, the Gateway checks if the request originated from an allowed domain and grants access accordingly. You can specify these domains in the Allowed Domains text box. This ensures that clients from a restricted domain cannot access an API even if an application key is stolen (when the key is placed in client-side JS code).

    Tip: When the client makes a request to an API that is only allowed to some domains, the request message must have an HTTP header to specify its domain name. Sending this header is mandatory only if the API is restricted to certain domains. An admin can configure this header name using <ClientDomainHeader> element under the <APIGateway> element in <APIM_HOME>/repository/conf/api-manager.xml.

    For example, if the file contains <ClientDomainHeader>domain</ClientDomainHeader>, then the API invocation request must contain an HTTP header called domain with values as shown in the example below: curl -v -H "Authorization: Bearer xxx" -H "domain: wso2.com" http://localhost:8280/twitter/1.0.0/search.atom?q=cat


Throttling tiers

Throttling allows you to limit the number of successful hits to an API during a given period of time, typically in cases such as the following:

  • To protect your APIs from common types of security attacks such as denial of service (DOS)
  • To regulate traffic according to infrastructure availability
  • To make an API, application or a resource available to a consumer at different levels of service, usually for monetization purpose

The following topics explain throttling:

Application-level throttling

Application-level throttling tiers are defined at the time an application is created in the API Store as shown below:

An application is a logical collection of one or more APIs and is required to subscribe to an API. Applications allow you to use a single access token to invoke a collection of APIs and to subscribe to one API multiple times with different SLA levels.

An application is available to a consumer at different levels of service. For example, if you have infrastructure limitations in facilitating more than a certain number of requests to an application at a time, the throttling tiers can be set accordingly so that the application can have a maximum number of requests within a defined time. The default throttling levels are are as follows:

  • Bronze: 1 request per minute
  • Silver: 5 requests per minute
  • Gold: 20 requests per minute
  • Unlimited: Unlimited access. The Default Application, which is provided out of the box has Unlimited tier set. You have the option to set it to a restricted limit.
Resource-level throttling

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. Resource-level throttling tiers are set to HTTP verbs of an API's resources when Managing APIs using the API Publisher portal as shown below:

The default throttling levels are Gold, bronze, silver and unlimited, as explained in the previous sections. 
When a subscriber views an API using the API Store, s/he can see the resource-level throttling tiers using the Throttle Info tab as follows:
Subscribers are not allowed to change these throttling tiers. They are simply notified of the limitations.
API-level throttling

API-level throttling tiers are defined when managing APIs using the API Publisher portal. The UI looks as follows:

After API-level throttling tiers are set and the API is published, at subscription time, the consumers of the API can log in to the API Store and select which tier they are interested in as follows:

 

According to the tiers the subscriber selects, s/he is granted a maximum number of requests to the API. The default tiers are as follows:

  • Bronze: 1 request per minute
  • Silver: 5 requests per minute
  • Gold: 20 requests per minute
  • Unlimited: Allows unlimited access (you can disable the Unlimited tier by editing the <TierManagement> node of the <APIM_HOME>/repository/conf/api-manager.xml file)

Setting tier permissions: Users with Manage Tiers permission can set role-based permissions to API-level access throttling tiers. This is done using the Tier Permissions menu in the API Publisher as shown below. For each tier, you can specify a comma-separated list of roles and either Allow or Deny access to the list. 

A subscriber logged into the API Store can consume APIs using a specific tier only if s/he is assigned to a role that is allowed access. In the API Store, the subscriber sees a list of tiers that is filtered based on the subscriber's role. Only the ALLOWED roles appear here. By default, all tiers are allowed to everyone.

IP-level throttling

In IP-based throttling, you can limit the number of requests sent by a client IP (e.g., 10 calls from single client).

  1. Log in to the management console and click the Resources -> Browse menu.
  2. Navigate to the tiers.xml file in the registry location /_system/governance/apimgt/applicationdata.

  3. Add your policy. For example, the throttling policy shown below allows only 1 API call per minute for a client from 10.1.1.1 and 2 calls per minute for a client from any other IP address.

    <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"  
    
    xmlns:throttle="http://www.wso2.org/products/wso2commons/throttle">   
    <throttle:MediatorThrottleAssertion>    
    <wsp:Policy>            
    <throttle:ID throttle:type="IP">10.1.1.1</throttle:ID>            
    <wsp:Policy>                
    <throttle:Control>                    
    <wsp:Policy>                        
    <throttle:MaximumCount>1</throttle:MaximumCount>                        
    <throttle:UnitTime>60000</throttle:UnitTime>                    
    </wsp:Policy>                
    </throttle:Control>           
    </wsp:Policy>        
    </wsp:Policy>
         
    <wsp:Policy>            
    <throttle:ID throttle:type="IP">other</throttle:ID>            
    <wsp:Policy>                
    <throttle:Control>                    
    <wsp:Policy>                        
    <throttle:MaximumCount>2</throttle:MaximumCount>                        
    <throttle:UnitTime>60000</throttle:UnitTime>                   
     </wsp:Policy>                
    </throttle:Control>            
    </wsp:Policy>        
    </wsp:Policy>    
    </throttle:MediatorThrottleAssertion></wsp:Policy> 

    If you need to add a list of IPs / subnets for throttling you can derive the IP range from CIDR (Classless Inter-Domain Routing) notation and add it to the throttling policy configuration as follows.

    Example :

    If IP / subnet is "10.1.1.1/27" in CIDR notation, the IP address range is between "10.1.1.1 - 10.1.1.30" (if we keep 31 for broadcast). Therefore you can add throttling for the IP range as follows.

    <throttle:ID throttle:type="IP">10.1.1.1 - 10.1.1.30</throttle:ID>

How throttling tiers work

With capability to define throttling at three levels, the final request limit granted to a given user on a given API is ultimately defined by the consolidated output of all throttling tiers together.

Example: Lets say two users subscribed to an API using the Gold subscription, which allows 20 requests per minute. They both use the application App1 for this subscription, which again has a throttling tier set to 20 requests per minute. All resource level throttling tiers are unlimited. In this scenario, although both users are eligible for 20 requests per minute access to the API, each ideally has a limit of only 10 requests per minute. This is due to the application-level limitation of 20 requests per minute.


API visibility and subscription

Visibility settings prevent certain user roles from viewing and modifying APIs created by another user role.

  • Public: the API is visible to all users (registered and anonymous), and can be advertised in multiple stores (central and non-WSO2 stores).
  • Visible to my domain: the API is visible to all users who are registered to the API's tenant domain.
  • Restricted by Roles: The API is visible to it's tenant domain and only to the user roles that you specify.

Given below is how visibility levels work for users in different roles:

  •  API creator and publisher roles can see all APIs in their tenant store even if you restrict access to them. This is because those roles have permission to view and edit all APIs in the API Publisher, and therefore, does not have to be restricted in the Store.
  • Anonymous users can only see APIs that have visibility as Public.
  • Registered users can see 
    • public APIs of all tenant domains  
    • all APIs in the registered user's tenant domain as long as the API is not restricted to a role that the user is assigned to

An API's visibility is directly related to the API's subscription availability because you cannot subscribe to something you don't see in the store. The diagram below depicts this relationship:

 


API documentation visibility

By default, any document associated with an API has the same visibility level of the API. That is, if the API is public, its documentation is also visible to all users (registered and anonymous). To enable other visibility levels to the documentation, go to <AM_HOME>/repository/conf/api-manager.xml file, uncomment and set the following element to true:

<APIPublisher>
   ....
   <EnableAPIDocVisibilityLevels>true</EnableAPIDocVisibilityLevels>
</APIPublisher>

Then, log in to the API Publisher, go to the Doc tab and click Add new Document to see a new drop-down list added to select visibility from:


You set visibility in the following ways:

  • Same as API visibility: Visible to the same user roles who can see the API. For example, if the API's visibility is public, its documentation is visible to all users.
  • Visible to my domain: Visible to all registered users in the API's tenant domain.        
  • Private: Visible only to the users who have permission to log in to the API Publisher Web interface and create and/or publish APIs to the API Store.

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 attributes:  

Attribute nameDescription
OAuth ScopesSee  OAuth scopes
URL Pattern

A URL pattern can be one of the following types:

  • As a url-mapping. E.g., /state/town/*
  • As a uri-template. E.g., /{state}/{town}

The terms url-mapping and uri-template come from synapse configuration language. When an API is published in the API Publisher, a corresponding XML definition is created in the API Gateway. This XML file has a dedicated section for defining resources. See examples below:

<resource methods="POST GET" url-mapping="/state/town/*">
<resource methods="POST GET" uri-template="/{state}/{town}">

url-mapping performs a one-to-one mapping with the request URL, whereas the uri-template performs a pattern matching.

Parametrizing the URL allows the API Manager to map the incoming requests to the defined resource templates based on the message content and request URI. Once a uri-template is matched, the parameters in the template are populated appropriately. As per the above example, a request made to http://gatewa_host:gateway_port/api/v1/texas/houston sets the value of state to texas and the value of town to houston. You can use these parameters within the synapse configuration for various purposes and gain access to these property values through the uri.var.province and uri.var.district properties. For more information on how to use these properties, see Introduction to REST API and the HTTP Endpoint of the WSO2 ESB documentation.

Also see http://tools.ietf.org/html/rfc6570 on URI templates.

HTTP VerbThe HTTP methods that specify the desired action to be performed on the resource. These methods can be GET, POST, PUT, DELETE or OPTIONS. Multiple methods can be selected.
Auth Type

The authentication type of each HTTP method of the resource. You can give one of the following:

  • None: No authentication is applied and the API Gateway skips the authentication process
  • Application: Authentication is done by the application. The resource accepts application access tokens.
  • Application User: Authentication is done by the application user. The resource accepts user access tokens.
  • Application and Application User: Both application and application user  level authentication is applied. Note that if you select this option in the UI, it appears as Any in the API Manager's internal data storage and data representation, and Any will appear in the response messages as well.

Note that for the resources that have HTTP verbs (GET, POST etc.) requiring authentication (i.e., Auth Type is not NONE), set None as the Auth type of OPTIONS. This is to support CORS between the API Store and Gateway. (The above screenshot shows this).

The auth type is cached in the API Manager for better performance. If you change the auth type through the UI, it takes about 15 minutes to refresh the cache. During that time, the server returns the old auth type from the cache. If you want the changes to be reflected immediately, please restart the server after changing the auth type.

A resource's parameters are cached in the resource cache at the API Gateway.

Once a request is accepted by a resource, it will be mediated through an in-sequence. Any response from the backend is handled through the out-sequence. Fault sequences are used to mediate errors that might occur in either sequence. The default in-sequence, out-sequence and fault sequences are generated when the API is published.


Cross-origin resource sharing

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g., fonts, JavaScript) of a Web page to be requested from another domain outside the domain from which the resource originated.

The Swagger API Console that is integrated in the API Manager runs as a JavaScript client in the API Store and makes calls from the Store to the API Gateway. Therefore, if you have the API Store and Gateway running on different ports, enable CORS between them. 

The CORS configuration is in <APIM_HOME>/repository/conf/api-manager.xml file. Given below is a sample code.

<CORSConfiguration>
    <Enabled>true</Enabled>
    <Access-Control-Allow-Origin>https://localhost:9443,http://localhost:9763</Access-Control-Allow-Origin>
    <Access-Control-Allow-Headers>authorization,Access-Control-Allow-Origin,Content-Type</Access-Control-Allow-Headers>
</CORSConfiguration>

The elements are described below:

XML ElementsValuesDescription
<Enabled>True/FalseUsed to enable/disable sending CORS headers from the Gateway. By default, CORS is enabled (True). This is needed for Swagger to function properly.
<Access-Control-Allow-Origin>HTTP and HTTPS Store Address. Change the Host and Port for correct values of your store. For example, https://localhost:9443,http://localhost:9763 The value of the <Access-Control-Allow-Origin header>. Default values are API Store addresses that are required for swagger to function properly.
<Access-Control-Allow-Headers>

Header values you need to pass when invoking the API. For example, authorization, Access-Control-Allow-Origin, Content-Type

Default values are sufficient for Swagger to function.

Change your code according to the sample given here.

 

If you try to invoke an API with inline endpoints, you add the CORS Handler in the <handlers> section of the API's configuration as follows. Find the API's configuration in the <APIM_HOME>/repository/deployment/server/synapse-configs/default/api folder.

 

<handlers>
   <handler class="org.wso2.carbon.apimgt.gateway.handlers.security.CORSRequestHandler"/>
</handlers>

OAuth scopes

Scopes enable fine-grained access control to API resources based on user roles. You define scopes to an API's resources. When a user invokes the API, his/her OAuth 2 bearer token cannot grant access to any API resource beyond its associated scopes.

You can apply scopes to an API resource at the time the API is created or modified. In the API Publisher, click the API -> Add menu (to add a new API) or the Edit link next to an existing API. Then, navigate to the Manage tab and scroll down to see the Add Scopes button. A screen such as the following appears:

Scope KeyA unique key for identifying the scope. Typically, it is prefixed by part of the API's name for uniqueness, but is not necessarily reader-friendly.
Scope NameA human-readable name for the scope. It typically says what the scope does.
Roles

The user role(s) that are allowed to obtain a token against this scope. E.g., manager, employee.

When the role you specify is in a secondary user store, you have to specify the role as <userstore name>/<role name>

To illustrate the functionality of scopes, assume you have the following scopes attached to resources of an API: 


Assume that users named Tom and John are assigned the employee role and both the employee and manager roles respectively.

Tom requests a token through the Token API as grant_type=password&username=nuwan&password=xxxx&scope=news_read news_write. However, as Tom is not in the manager role, he will only be granted a token bearing the news_read scope. The response from the Token API will be similar to the following:

"scope":"news_read","token_type":"bearer","expires_in":3299,
"refresh_token":"8579facb65d1d3eba74a395a2e78dd6",
"access_token":"eb51eff0b4d85cda1eb1d312c5b6a3b8"

Next, John requests a token as grant_type=password&username=john&password=john123&scope=news_read news_write. As john has both roles assigned, the token will bear both the requested scopes and the response will be similar to the following:

"scope":"news_read news_write", "token_type":"bearer", "expires_in":3299, "refresh_token":"4ca244fb321bd555bd3d555df39315",
"access_token":"42a377a0101877d1d9e29c5f30857e"

This means that Tom can only access the GET operation of the API while John can access both as he is assigned to both the employee and manager roles. If Tom tries to access the POST operation, there will be an HTTP 403 Forbidden error as follows:

<ams:fault xmlns:ams="http://wso2.org/apimanager/security">
   <ams:code>900910</ams:code>
      <ams:message>The access token does not allow you to access the requested resource</ams:message>
      <ams:description>Access failure for API: /orgnews, version: 1.0.0 with key: eb51eff0b4d85cda1eb1d312c5b6a3b8
   </ams:description>
</ams:fault>

Tip: To invoke an API protected by scopes, you need to get an access token via the Token API. Tokens generated from the My Subscriptions page in the API Store will not work.


API templates

An API template is its XML representation, which is saved in <APIM_HOME>/repository/resources/api_templates/velocity_template.xml file. This file comes with the API Manager by default. You can edit this default template to change the synapse configuration of all APIs that are created.

If you are using a distributed API Manager setup (i.e., Publisher, Store, Gateway and Key Manager components are running on separate JVMs), edit the template in the Publisher node.


Endpoints

An endpoint is a specific destination for a message such as an address, WSDL, a failover group, a load-balance group etc.

WSO2 API Manager has support for a range of different endpoint types, allowing the API Gateway to connect with advanced types of backends. It supports HTTP endpoints, URL endpoints (also termed as address endpoint), WSDL endpoints, Failover endpoints, Load-balanced endpoints. For more information about endpoints and how to add, edit or delete them, see the WSO2 ESB documentation.

Note the following:

  • You can expose both REST and SOAP services to consumers through APIs.
  • You cannot call backend services secured with OAuth through APIs created in the API Publisher. At the moment, you can call only services secured with username/password.
  • The system reads gateway endpoints from the <JAVA_HOME>/Repository/conf/api-manager.xml file. When there are multiple gateway environments defined, it picks the gateway endpoint of the production environment. You can define both HTTP and HTTPS gateway endpoints as follows:

    <GatewayEndpoint>http://${carbon.local.ip}:${http.nio.port},https://${carbon.local.ip}:${https.nio.port}</GatewayEndpoint> 
  • If both types of endpoints are defined, the HTTPS endpoint will be picked as the server endpoint.

    Tip: When you define secure (HTTPS) endpoints, set the <parameter name="HostnameVerifier"> element to AllowAll in <APIM_HOME>/repository/conf/axis2/axis2.xml file's HTTPS transport sender configuration:

      <parameter name="HostnameVerifier">AllowAll</parameter>

    If not, the server throws an exception.

  • When creating (or updating) Failover endpoints through the Publisher UI (in the Implement tab), you need to go into the Advanced Options of each endpoint and specify a set of Error Codes for the endpoint to fail over on and take off the Initial Duration by setting its value to -1.


Sequences

The API Manager has a default mediation flow that is executed in each API invocation. There are 3 default sequences engaged as in, out and fault.


Caching

For information on configuring caching response messages and caching API calls at the Gateway and Key Manager server, see Configuring Caching.

  • No labels