Application Integration (On-Premises) : Creating REST applications : How REST Processing Works : How webMethods Integration Server Processes REST Requests
How webMethods Integration Server Processes REST Requests
When Integration Server processes a REST request, it parses the tokens and identifies the HTTP method to execute, locates the resource to act upon, and passes additional information as input parameters to the services you wrote for your application. 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, and _delete, and they are stored in the folder for the resource. For more information, seeServices.
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 would parse 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 would parse 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 would parse 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 would parse 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.
Copyright © 2015- 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback