Configuring a REST Resource Using the Legacy Approach

Designer 10.7 | webMethods Service Development Help | Appendix | Usage Notes on REST | 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.

Note:
The ability to create a REST resource using the legacy approach was deprecated in Designer and Integration Server version 10.5 and removed in version 10.7. However you can still edit and use any legacy REST resources that you created in versions of Integration Server prior to 10.7.

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.