Policy developers can use the REST API development wizard in Policy Studio to create new REST APIs based on existing back-end REST and non-REST APIs in an iterative development cycle. For example, this includes exposing a SOAP Web service, or a cloud-based application as a REST API. Creating new REST APIs using Policy Studio is known as API development. You must specify a custom routing policy for REST API methods. You can specify optional policies for request and response processing as required.
The API Catalog in the Policy Studio tree stores information about REST APIs created using the REST API development wizard. When new REST APIs are added in the API Catalog, they can then be registered in API Manager for consumption by API consumers and administration by API administrators.
APIs created using the REST API development wizard are registered by importing as a back-end API into API Manager. Registered APIs are governed by the API Gateway using policies defined in the client registry. API administrators can use API Manager to manage registered APIs, and API consumers can use API Manager to consume registered APIs in their client applications.
Note |
|
The API Catalog
is displayed under the Listeners
> REST API Registration
node in the Policy Studio tree. When a REST API is added to this repository, it becomes virtualized
by the API Gateway. A virtualized REST API is assigned a path that gives it a namespace in a running API Gateway instance (for example, /flickr/v1
). This means that all of its methods reside under a URL with that path (for example, /flickr/v1/photos
). You can view the list of virtualized REST APIs by selecting the APIs
node in the tree.
The following example shows a virtualized Flickr REST API:
Because the REST API encompasses an inbound listener and resolver in a running API Gateway instance, the paths associated with the API are also displayed in the tree (for example, under Listeners > API Gateway > Default Services > Paths). These REST API paths are read-only under the Listeners node. You can create or update these paths as described in Virtualize a REST API.
Each REST API consists of zero or more REST API methods. Each method can provide custom polices for request, routing, and response processing. You can view the list of methods for a virtualized REST API by clicking the specific APIs node in the tree. The following example shows API methods for the virtualized Flickr REST API:
To virtualize a REST API in the repository, perform the steps described in this section.
Perform the following steps to define the REST API:
Flickr API
). 1.0
. ${environment.VINSTDIR}/docs/REST_API_NAME/REST_API_NAME.md |
Perform the following steps to configure how the REST API is exposed:
/flickr/v1
). This is the path that the API Gateway listens on for messages for the REST API. This path gives the API a namespace in the running API Gateway instance, under which its methods can reside (for example, /flickr/v1/getPhoto
).When the REST API has been virtualized in the repository, it is displayed when you select the APIs node. At any stage, you can select the REST API in the panel on the right, and click Edit to edit any of its configuration settings. Similarly, click Remove to remove the API from the repository.
To virtualize a REST API method in the repository, perform the steps described in this section.
Perform the following steps to define the REST API method:
Photo Search
).${environment.VINSTDIR}/docs/REST_API_NAME/REST_API_METHOD_NAME.md |
Perform the following steps to configure the exposure settings:
/getPhoto
).Note | You can also specify path parameters (for example, an inbound path of /getPhoto/{userID} , where userID
is a variable part of the path). When you specify an inbound path parameter, the parameter (in this case, userID ) is automatically added in the Inbound parameters table below. |
userID
).string
.400
).Bad Request
).You can specify the following policy and monitoring settings for the API method:
authentication.subject.id
attribute stores the identifier of the authenticated user (for example, the user name or X.509 Distinguished Name). When the API method has been virtualized in the repository, it is displayed under the APIs node. At any stage, you can select the REST API method in the panel on the right, and click Edit to edit any of its configuration settings. Similarly, click Remove to delete the API method from the repository.
The REST API method wizard enables you to virtualize REST API methods in the API Catalog, and to specify any inbound path parameters (for details, see Specify exposure settings).
For example, given a virtualized REST API such as the Yahoo Finance API, you can use the REST API method wizard to specify inbound stock quote URL path parameters, which can then be mapped to specific query string parameters. This enables you to expose an inbound path such as /stock/quote/{symbol}
, and to map {symbol}
to the s
parameter in the query string. You can then make parameterized API calls such as the following at runtime:
finance.yahoo.com/d/quotes.csv?s=symbol&f=sb2b3jk |
This call returns a stock quote such as the following at runtime:
AMZN 272.99 270.03 185.51 284.72 |
The REST API parameter mappings supported by the API Gateway are as follows:
Parameter type | Mapping |
Query string |
|
Path |
|
Form-encoded body |
|
Header |
|
You can configure any required mappings using request, routing, or response policies. For more details, see Configure policies and monitoring settings. For example, you can use a Set Header filter to map to a header parameter, or a Scripting or Set Message filter to map to a path or query parameter.
When inbound parameters are specified in your REST API, you can access their values on the API Gateway message whiteboard at runtime using the following selectors in your policies:
${params.path.param_name}
${params.query.param_name}
${params.form.param_name}
${params.header.param_name}
The API Gateway parses the input parameters and auto-generates the message attributes. The configured mappings take these message attributes and use them for the output parameter values (query, form, path, or header).
When the message content is JSON, you can also access fields in the message body using ${params.body.field}
. For example, given the following JSON message content:
{ "id":"28a384e7-0b13-4679-ae1c-0c63666d3d8e" "activities": ["running", "swimming", "cycling"], "subObject": "foo": "bar", "hello": "world", "yetAnotherObject": { "array": ["a", "b", "c"], "val": "greetings from yetAnotherObject" } } } |
You can use the following selectors to access the JSON message body content in your policy at runtime:
Selector | Value |
${params.body.id}
|
28a384e7-0b13-4679-ae1c-0c63666d3d8e
|
${params.body.activities[1]}
|
swimming
|
${params.body.subObject.hello}
|
world
|
${params.body.subObject.yetAnotherObject.array[0]}
|
a
|
For more details on configuring policies, filters, and selectors, see the API Gateway Policy Developer Guide.
When you create an API in Policy Studio and register it in API Manager, you can use the API Gateway Manager web console to monitor the API at runtime.
When invoking a REST API developed in Policy Studio, by default, the authenticated subject displayed on the Traffic tab is blank:
To override the default behavior, you must set the ${authentication.subject.id}
message attribute in one of the policies configured for the API (request, routing, or response).
The following shows example shows how to configure this using a Set Attribute filter:
When configured in a policy, the subject is displayed in API Gateway Manager as follows:
For details on using API Gateway Manager, see the API Gateway Administrator Guide.