...

During the automated migration process, settings from legacy input modes are mapped to the new input modes. The legacy REST Client had Form, Literal, and Scripted input modes. 

Image Modified

The current REST Client has constrained (OpenAPI/Swagger, RAML, WADL) and unconstrained service definition modes.

Image RemovedImage Added

Migration is performed as follows:

...

With fixed values, you can access data source values using ${var_name} syntax. You can also use the environment variables that you have specified. For details about environments, see Configuring Testing in Different Environments or Configuring Virtualize Environments.
Image RemovedIf the URL uses environment variables, the Resolved URL field will display how they resolve into an actual URL.

Image RemovedImage Added

If the environment variable has been masked, however, the Resolved URL field will not show the actual value  (also see Masking a Variable Value).

Image Modified

Parameters can be configured in the Path and Query tabs, as described in Parameter Configuration. Any changes made in the URL will automatically be propagated to the Path/Query table. Also, the URL will automatically be updated to reflect any changes made to the Path/Query table. 

...

• RAML URL: A specific RAML URL, or a variable referencing a RAML URL. The value entered here will be used to populate the Base URL and Operation controls.
• URL: A preview of the complete URL for accessing the service; it is constructed from the Base URL, Operation, and the values entered in the Path / Query tabs. Note that this field shows the full constructed URL, but does not resolve variables. See Resolved URL to view resolved variables. 
• Resolved URL: The resolved RAML URL. If you are configuring the tool using environment variables, this will show you how they resolve into an actual URL. For example, assuming that HOST and PORT are environment variables, and var_name is a data source column, a URL of http://${HOST}:${PORT}/some/url/${var_name} might result in a Resolved URL of http://localhost:8080/some/url/${var_name}
• Base URL: Specifies the protocol to use (HTTP or HTTPS), host, port, and path.
• Operation: When a RAML definition is configured, you can select an operation and HTTP Method from this box. The Form Input views for the Path/Query table as well as the Payload tab will update depending on the selected operation and HTTP Method.
  
  Image Modified
  
  

You can set the Base URL field to use constrained (from the specified RAML URL), fixed (modifiable), or scripted inputs. 

• For details about scripting values, see Extensibility and or Scripting Basics.

• With fixed values, you can access data source values using ${var_name} syntax. You can also use the environment variables that you have specified. For details about environments, see Configuring Testing in Different Environments or Configuring Virtualize Environments.

...

• OpenAPI/Swagger URL: A specific OpenAPI/Swagger URL or a variable referencing a OpenAPI/Swagger URL. The value entered here will be used to populate the Base URL and Operation controls.
• URL: A preview of the complete URL for accessing the service; it is constructed from the Base URL, Operation, and the values entered in the Path / Query tabs. Note that this field shows the full constructed URL, but does not resolve variables. See Resolved URL to view resolved variables.
• Resolved URL: The resolved OpenAPI/Swagger URL. If you are configuring the tool using environment variables, this will show you how they resolve into an actual URL. For example, assuming that HOST and PORT are environment variables, and var_name is a data source column, a URL of http://${HOST}:${PORT}/some/url/${var_name} might result in a Resolved URL of http://localhost:8080/some/url/${var_name}
• Base URL: Specifies the protocol to use (HTTP or HTTPS), host, port, and path.
• Operation: When a OpenAPI/Swagger definition is configured, you can select an operation and HTTP Method from this box. The Form Input views for the Path/Query table as well as the Payload tab will update depending on the selected operation and HTTP Method.
  
  Image Modified
  
  

You can set the Base URL field to use constrained (from the specified OpenAPI/Swagger URL), fixed (modifiable), or scripted inputs. 

• For details about scripting values, see Extensibility and or Scripting Basics.

• With fixed values, you can access data source values using ${var_name} syntax. You can also use the environment variables that you have specified. For details about environments, see Configuring Testing in Different Environments or Configuring Virtualize Environments.

...

• WADL URL: A specific WADL URL, or a variable referencing a WADL URL. The value entered here will be used to populate the Base URL and Operation controls.
• URL: A preview of the complete URL for accessing the service; it is constructed from the Base URL, Operation, and the values entered in the Path / Query tabs. Note that this field shows the full constructed URL, but does not resolve variables. See Resolved URL to view resolved variables.
• Resolved URL: The resolved WADL URL. If you are configuring the tool using environment variables, this will show you how they resolve into an actual URL. For example, assuming that HOST and PORT are environment variables, and var_name is a data source column, a URL of http://${HOST}:${PORT}/some/url/${var_name} might result in a Resolved URL of http://localhost:8080/some/url/${var_name}
• Base URL: Specifies the protocol to use (HTTP or HTTPS), host, port, and path.
• Operation: When a WADL is configured, you can select an operation and HTTP Method from this box. The Form Input views for the Path/Query table as well as the Payload tab will update depending on the selected operation and HTTP Method.
  
  Image Modified
  
  

You can set the Base URL field to use constrained (from the specified OpenAPI/Swagger URL), fixed (modifiable), or scripted inputs. 

• For details about scripting values, see Extensibility and or Scripting Basics.

• With fixed values, you can access data source values using ${var_name} syntax. You can also use the environment variables that you have specified. For details about environments, see Configuring Testing in Different Environments or Configuring Virtualize Environments.

...

If you switch from a constrained  mode (Service Definition set to RAML, OpenAPI/Swagger, or WADL) to unconstrained mode (Service Definition set to None), you will have the option of automatically populating the unconstrained view with values from the constrained view.

For example, assume you had the following in WADL view:

Image Removed

If you chose to populate the unconstrained view from the WADL one, you would get the following:

The following example contains several configurations that be automatically populated after switching modes:

Image Added

Switch the mode and confirm that you want to populate the client configuration values using the values from the service definition.

Image Added

The client will be updated after confirming to override the service definition configurations:

Image AddedImage Removed

Anchor
Parameter Configuration Parameter Configuration

Parameter Configuration

...

The Paths tab lets you configure template parameters for the currently-selected operation. For example, a path of "/parabank/services/bank/accounts/{accountId}" has a single path parameter: "accountId". In  In the unconstrained mode, parameters can be fixed, parameterized, or scripted.

Image Modified

In the constrained modes, parameters can be set to fixed, parameterized, automatically-generated, or scripted values.

Image Modified

Query Parameters

...

In unconstrained mode, parameters can be fixed, parameterized, or scripted.

Image Modified

In the constrained modes, parameters can be set to fixed, parameterized, automatically-generated, or scripted values. 

...

Select the appropriate protocol from the Transport drop-down list, then configure its properties, which are described in the following sections:

SOAtest

• HTTP 1.0 1
• HTTP 1.1

Virtualize

• HTTP 1.0
• HTTP 1.1

Misc Tab

The following options are available in the Success Criteria Misc tab of the REST Client tool:

• Valid HTTP Response Codes: Allows you to customize the tool behavior so that it succeeds with HTTP response codes outside the 2xx range. Specify single codes and/or code ranges as a comma-separated list. 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").

• Timeout after (milliseconds): Specifies the length of delay (in milliseconds) after which your FTP, telnet, or HTTP requests should time out. The Default setting corresponds to the timeout set in the Preferences panel. The Custom setting allows you to enter a timeout. A non-positive timeout value can be entered to specify an infinite timeout.

  • Fail the test on timeout: Select this option if you want the tool to fail on the specified timeout.
  • Pass the test only if a timeout occurred: Select this option to have the tool pass if the specified timeout occurs (i.e. the test does not finish execution within the specified time).

• Outgoing Message Encoding: Choose Custom from the drop-down menu and choose an encoding for the outgoing message. The default is to use the encoding configured in the immediate parent test suite (see Specifying Client Options). You can also specify this option globally in the Parasoft Preferences Misc settings (see Additional Preference Settings Settings).

Related Tutorials

The following tutorial lesson demonstrates how to use this tool:

...