Configuring a REST Resource Using the Legacy Approach

Processing Requests Using Partial Matching of URL Aliases

Setting Up a REST Application on Integration Server

If you already have a REST resource created using the legacy approach, you can configure them in Integration Server. On Integration Server the resources of your application are represented as folders within a package. For each resource, you will write individual services for the HTTP methods that you want Integration Server to execute against the resource. Those services must be named _get, _post, _put, _patch, and _delete, and they are stored in the folder for the resource. For more information, see Services for REST Resources Configured Using the Legacy Approach.

A simple REST request looks like this:

METHOD /directive/resource_type/resource_id HTTP/1.1

Where...	Is the...
METHOD	HTTP request method.
directive	The type of processing to perform.
resource_type/resource_id	Resource to act upon.

Consider a Discussion application that maintains a database of discussions about different topics. The following examples show how Integration Server would parse these REST requests.

Example 1

Here is a request to obtain a list of all topics contained in the database, and how Integration Server parses the request:

GET /rest/discussion/topic HTTP/1.1

Where...	Is the...
GET	Type of HTTP method to perform. Integration Server maps this value to the corresponding service on Integration Server, in this case, the _get service.
rest	This is a directive which shows the type of processing to perform. In this case, Integration Server REST processing. Note: For more information about directives, see
discussion/topic	Location of the _get service for this resource on Integration Server. In this example, the _get service resides in the topic folder under the discussion folder (discussion.topic).

Example 2

Here is a request to display information about topic number 3419, and how Integration Server parses the request:

GET /rest/discussion/topic/3419 HTTP/1.1

Where...

Is...

3419

This is a $resourceID. An instance of a resource passed into a service as the $resourceID variable. In the example, the $resourceID variable narrows the focus of the GET request to topic 3419.

Note:Integration Server assigns the first token after the folder(s) to the $resourceID parameter. To determine whether a token represents a folder or the $resourceID, Integration Server looks in the current namespace for a folder that has the same name as the token. If it does not find a folder with this name, Integration Server assigns the token to the $resourceID variable. In other words, the first token (after the directive) that does not correspond to a folder becomes the $resourceID.

Example 3

Here is a request to display information about a particular comment, 17 for example, and how Integration Server parses the request:

GET /rest/discussion/topic/3419/comment/17 HTTP/1.1

Where...	Is...
comment/17	This is a $path variable. Additional information that further narrows the information about the resource. This information is passed into a service as the $path variable. In the example, comment/17 further narrows the focus of the GET request to comment 17.

Example 4

Here is a request to display information contributed by participant Robertson in 2009 about topic 17, and how Integration Server parses the request:

GET /rest/discussion/topic/3419/comment/17?year=2009&name=Robertson HTTP/1.1

Where...	Are...
year and name	Input variables that are specific to your application. Tokens specified after the ? must be entered as name/value pairs. In this example, year=2009 and name=Robertson narrow the focus of the GET request to entries that participant Robertson added to comment 17 in 2009.