REST Virtual Services

In ReadyAPI, you can create a REST virtual service from scratch. This means that you create an empty service and then add virtual operations to it manually.

A faster approach is to create a REST virtual service from an OpenAPI, Swagger or WADL specification. In this case, ReadyAPI will automatically create virtual operations for the operations it finds in the specification (it can do this for all the operations or some of the operations). If the specification is yet not part of your ReadyAPI project, it will be included into the project. See Generating Virtual Services.

One more way to create a REST virtual service and add operations to it is to “discover” an existing REST service and create virtual operations from it: you activate a special recording mode in ReadyAPI and send requests to an existing web service. ReadyAPI traces the traffic and creates a virtual operation from the requests and responses it detected. See Recording Virtual Services (Discovering).

To add new operations to a REST virtual service, simply click Action on the service editor toolbar:

Click the image to enlarge it.

One more way is to use the Generate Virtual Service command. When you select it, ReadyAPI displays the dialog, in which you can select the operations which ReadyAPI will virtualize:

Click the image to enlarge it.

You can also quickly create an operation by cloning an existing operation: click Duplicate VirtAction for an existing operation and then modify its properties in the editor on the right:

Click the image to enlarge it.

One more possible way to add operations to a virtual service is to record traffic to some existing web service: you switch the service to a special recording mode and send requests to the existing web service. ReadyAPI will trace requests and responses and create virtual operations from them. See Add Recorded Operations to Virtual Service.

When you send a request to a REST virtual service, you send the request to a certain resource (or page) on that server. A typical request URL looks like this:

http://virt-address:port/virt-path/resource-path?parameters

Unlike SOAP and JMS virtual services, for REST virtual services, the request type (GET, POST, PUT and so on) matters, as the REST services can implement various virtual operations for the same resource path (that is, these operation match to the same resource path, but use different request types).

• When a REST virtual service receives a request, it extracts the resource path from the URL. To do this, it drops the service address, port, service path and parameters and uses the rest substring as the resource path. Once the virtual service gets the resource path, it starts searching for the matching virtual operation by comparing the operation type and resource path with the request type and resource path. If the operation is found, the virtual service uses dispatch settings to select a response for the reply. If the service fails to find an operation, it returns the 500 Internal Server Error.

  If the service has two virtual operations that match the request type and resource path, it will use the first found operation.

• When setting the resource path for an operation, do not specify the query parameters, that is, the parameters that follow a question mark (?) in the URL string. The virtual service ignores these parameters when forming the resource path for the search from the request URL (see above). If the parameters are present in the resource path of a virtual operation, this operation will not match any incoming request, that is, it will simply not work.

  If you need to provide different responses for different parameter values, create one virtual operation for the request and use the Parameter or Script dispatch types to analyze parameter values and to select the response you need.

• The resource path of an operation can have path parameters, that is, the parameters that are part of the resource path (they are also called TEMPLATE parameters). For example, for the following request –

  http://localhost:8088/my-petshop-virt/sale-item-details/1234/price

  – you can create an operation with the resource path like this:

  /sale-item-details/{sale-item-id}/price

  The curly braces in the resource path indicate that the URL path has an arbitrary value in this place.

  You can use several placeholders in the resource path, for example:

  /order-details/{order-id}/discountable/{position}/name

  Be careful. The REST virtual services do not make any assumptions on the placeholder types. For instance, the following two virtual operations will match to the same request:

  /sale-items/{item-id}/price
/sale-items/{item-brief-name}/price
  

You can run REST virtual services both on local and remote machines:

• On local computers, you can run them from within ReadyAPI and from the command-line runner.

• To run virtual services on remote machines, you need VirtServer there. Alternatively, you can save the virtual service as a WAR file (Web Application aRchive) and run it on a container like Tomcat.

For complete information, see Running Virtual Services.

Properties

REST Virtual Service Properties

REST Request Properties

REST Response Properties

Transaction Log Pages

REST Request Log

REST Response Log