Configuring a REST Resource Using the Legacy Approach

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.

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.

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 Controlling the Use of Directives.
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).

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.

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.

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

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.