A URL pattern can be one of the following types:
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:
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
Also see http://tools.ietf.org/html/rfc6570 on URI templates.
|HTTP Verb||The 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.|
The authentication type of each HTTP method of the resource. You can give one of the following:
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 (Cross Origin Resource Sharing) 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.
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
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:
|<Enabled>||True/False||Used 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, ||The value of the |
Header values you need to pass when invoking the API. For example,
|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
<handlers> <handler class="org.wso2.carbon.apimgt.gateway.handlers.security.CORSRequestHandler"/> </handlers>
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.