Trading Networks 10.7 | Administering and Monitoring B2B Transactions | Service Development Help | Appendix | Usage Notes on REST | Configuring a REST Resource Using the Legacy Approach
 
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.