Call REST Web Service
The Call REST Web Service action gets data from different sources on the Internet. In the step, requests made to the URI of the source return a response with a payload formatted in HTML, XML, JSON, or other format. The response is either presented in HTML form as the current page or stored in a variable.
If the web service returns a fault, the message is not returned by the action. Instead, the action will generate an error which can be handled using the standard error handling mechanisms.
The supported authentication for this action step includes Negotiate, NTML, Digest, Basic, and OAuth. You can configure the authentication method for this step on the All Loading tab by clicking More below Options in the step properties. For more information on the protocols, see Web Authentication. When setting the Negotiate protocol parameters for the entire robot or for this step only, the spn.txt file is not used.
Properties
The Call REST Web Service action can be configured using the following properties:
- URL
-
The base URL of the web service, excluding parameters. The URL can be specified in several ways using a URL Selector.
- Request
-
Here, you specify the type of request to be made. REST supports five basic operations:
- GET
-
Used for querying data. For GET requests, you can specify a number of parameters and/or files as name/value pairs to pass with the request. Click '+' to add a new parameter or upload a file.
- POST
-
Used for updating selected parts of data. For POST requests, you can either specify a number of parameters as name/value pairs or give the entire body of the request. If you specify the request with parameters, you must select whether to use POST (application/x-www-form-urlencoded) or MULTIPART (multipart/form-data) to encode the parameters. If you give the entire ('raw') body of the request, you must specify the content type of the request data.
For POST and PUT requests, MULTIPART encoding can be selected to enable file uploads. If a binary variable is selected as the value of a File Upload parameter, the bytes are submitted as-is. If Base 64 encoding is desired, the value of the parameter should be an expression base64Encode(data) where data is the name of the variable containing the binary value. In that case, it is also recommended to specify the value base64 as Content Transfer Encoding - otherwise, this field can normally be left blank.
- PUT
-
Used for replacing data. See POST for a description of the different ways of specifying a PUT request.
- DELETE
-
Used for deleting data. For DELETE requests, you can specify a number of parameters and/or files as name/value pairs to pass with the request. Click '+' to add a new parameter or upload a file.
- PATCH
- Used for modifying data. For PATH requests, you can specify a number of parameters and/or files as name/value pairs to pass with the request. Click '+' to add a new parameter or upload a file.
- Accept
-
The content types that will be accepted as response. By default, any type of response will be accepted. The accepted content types can be specified in several ways using the Value Selector.
- Encoding
-
The encoding that will be used to encode special characters in the request. The encoding used for decoding the response, is controlled using the step option, on the Page Loading Tab.
- Output
-
Here, you select what happens to the output of the web service call.
- Load in browser
-
The result is loaded into the current window, just as if it had been the result of a Load Page action. You may configure the behavior of the browser using the Options property described below.
- Store in variable
-
The result is stored in the selected variable.
- Preemptive Auth
- Enable to pre-send the authorization header to accelerate the authorization process. When preemptive authentication
is enabled,
Design Studio
sends the
Basic or
Digest authentication response before the server returns a 401 Unauthorized response. To use preemptive
authentication, you need to configure default credentials in the
Options below.
When using the Digest authentication, each algorithm has two variations: session and non-session. A non-session algorithm is defined as <name>, such as SHA-256, and non-session is defined as <name>-sess, such as SHA-256-sess.
- Options
-
You can override the robot's options with the step's own options. An option that is marked with an asterisk in the Options dialog box will override the one from the robot's configuration. All other options will be the same as specified for the robot.