Applies to ReadyAPI 2.8, last modified on August 16, 2019

In ServiceV, you can create virtual services (virtual APIs) that emulate behavior of real RESTful web services. For detailed information on how to perform this or that action, see topics of the ServiceV section. This topic highlights specifics of REST virtual services in ServiceV.

Create REST Virtual Services

In ServiceV, 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, ServiceV 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).

Add Operations

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

Service virtualization and API testing: Adding a new operation to a REST virtual service

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:

Service virtualization and API testing: Using the Generate Virtual Service command

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:

Service virtualization and API testing: The Duplicate VirtAction command

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.

Send Requests

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).

Request and Response Dispatching

  • 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

Run REST Virtual Services

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.

Reference

See Also

Virtual Service Specifics

Highlight search results