Configuring a REST Resource Using the Legacy Approach

Hybrid Integration 10.2 | Integrating On-Premises Applications | Creating REST applications | Configuring a REST Resource Using the Legacy Approach

Processing Requests Using Partial Matching of URL Aliases

You can use the legacy approach to create a new REST resource that include the REST resource folder and the flow services that correspond to HTTP methods. REST resources generated using the legacy approach are invoked with the rest directive. For information about the procedure to configure REST resources, see the webMethods Service Development Help.

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 Setting Up a REST Application Using the Legacy REST Approach.

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	Type of processing to perform, in this case, Integration Server REST processing. Note: For more information about directives, see webMethods Integration Server Administrator’s Guide.
discussion/topic	Location of the _get service for this resource on Integration Server. In this example, the _get service resides in the topic folder in 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

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	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.