In this section:
REST Clients are tools that check the functionality of RESTful services. You can add REST Clients to your scenarios and configure them to suit your testing needs. You can also create and run a job for executing the related test scenarios with the appropriate environment provisioned. Use these tests to check the health of specific components and to automate testing during provisioning.
The REST Client interface in CTP is designed to quickly enable you to create new REST client tools. Use the SOAtest desktop to create more advanced REST Clients with more complex configurations, such as message payloads defined by custom scripts. See REST Client.
Creating REST Clients from Traffic
If you have a traffic file that captures traffic for RESTful services, you can generate a test scenario with REST Clients configured to test the recorded traffic. For details, see Creating New Test Scenarios and Test Suites.
Adding a REST Client
- In the left pane, select the .tst or test suite where you want the new REST client added.
- Choose Add REST Client from the page-level action menu.
- (Optional) Modify the name of the newly-created tool.
- Configure the tool as described below and click Save.
The new tool will be added at the end of the selected test suite.
Configuring a REST Client
- (Optional) If you want to associate the client with requirements, tasks, or other development artifacts, click the + button in the requirements section and add details when prompted.
The default type is@req
, but you can click on the type field to choose a different artifact for associations.
- If the containing test suite includes multiple data sources, you can review and change which data source is used to parameterize this REST Client. See Parameterizing with Data Source and Data Bank Values for details.
- Choose the HTTP method to execute from the Method drop-down menu.
Specify the URL, including queries, for accessing the resource.
Tip: Using {var_name}
If you’re familiar with SOAtest, you can use the standard ${var_name} notation to reference environment variables, test suite variables, and data source values that are defined for the test scenario. This applies to both URL and Payload.
When you are working with JSON, a special notation is used for parameterizing a number or boolean field within a JSON message: ${number:<value>} or ${boolean:<value>}. For example, to parameterize a number field with the column Count, you would use ${number:Count}.
- (Optional) You can configure the client so that it succeeds with HTTP response codes outside the 2xx range. Specify single codes and/or code ranges as a comma-separated list in the Valid response field. For example, if you use "302, 500-599", a 302 code or any code in the 5xx range will be accepted. If you're using a parameterized value, be sure that the value in the data source uses this same format (e.g., "302, 500-599").
- (Optional) Specify a length of time in ms before the client timeouts if it does not receive a response.
(Optional) If the service requires authentication, enable the Enable HTTP authentication option and specify login credentials.
(Optional) Add HTTP headers if you want to override the default headers.See HTTP Headers for additional information. Choose Literal or Table mode from the HTTP headers drop-down menu to enter values in a text area or build the header using a table format.
Literal modeTable mode- (Optional) If you want to reset cookies before sending a request, enable the Rest existing cookies before sending request option.
- If you have selected a method that sends data (e.g., PUT, POST), use the Payload controls to specify the payload for the message that will be sent.
- Ensure that the appropriate payload format and media type are selected (in the Format and Content type boxes).
- Specify the payload in the literal text editor, the JSON editor, or the XML editor (see Editing JSON Messages and Editing XML Messages for details and tips).