Understanding Basic Concepts

A virtual service is a mock of a real web service. It defines requests the service will receive and responses it will send to clients to reply to requests. A virtual service acts as a real web service: it runs on a specific URL and port, you can send requests to it, and it will reply with responses. However, the virtual service cannot run itself, it requires a runner: either ReadyAPI, or VirtServer (you need the latter to run virtual services on remote machines). In ReadyAPI, we also call virtual services virtual APIs.

You can create as many virtual APIs in your project as needed. You can view them in the Navigator panel under the APIs (Virtual) node (see the image below).

When creating a virtual service, you define incoming messages (requests) that the service will receive and responses for them. You do this in the virtual service editor:

Click the image to enlarge it.

We call the combination of an incoming request and outgoing response an operation (or an action). As you can see, a request can have several responses defined for it.

You can specify the operations manually in the virtual service editor, or, if you have an OpenAPI, Swagger, WADL or WSDL specification for your service, you can command ReadyAPI to load operation definitions from this specification when creating the virtual service. One more way to get a list of service operations is to record traffic to your live service: ReadyAPI will retrieve information on requests and will create operations in your virtual service.

• When a virtual service receives a request, it finds the virtual operation matching the request. To find the operation, the virtual service analyzes various request properties. The exact algorithm depends on the service type: SOAP virtual services check the requested resource path in the URL, REST virtual services check the request type (GET, POST, and so on) and the URL path, JMS virtual services check the JMS session and the topic (or queue). For detailed information, see Virtual Service Specifics.

  If the service finds an operation, it continues processing. Otherwise, it returns the “500 Internal Server Error” error.

• After the virtual service finds an operation, it needs to select a response for the incoming request. The service selects a response based on the Dispatch settings you specify for the operation. The choice is based on the request parameters, request contents or in other ways. See Dispatch Settings.

  A virtual service can forward a request to some live web service, receive a response and transfer it back to the request sender. That is, it can act as a transparent proxy between the client and live service. This process is called routing. You can configure your virtual service to route all requests or only some of them. In this tutorial, we will not route requests. You can do this for your virtual services, if needed. See Request Routing for details.

• You specify the response contents in the response editor. The response can have attachments. You can also insert project or service properties in it, or load and insert data from Excel sheets, databases, CSV files and other data sources.

• Here is a brief description of the service editor pages:

  

  Click the image to enlarge it.