Basic Concepts

Web services are client/server applications in which clients and servers exchange data over the Web through the HTTP protocol or some other protocol based on HTTP. Examples of such applications include navigation software, online bank clients, weather monitoring systems, and so on.

The URLs, to which clients send requests, contain information on the tested server (host), the port number to be used for communication, and the requested server resource, for example, a page or file path:

Requests that clients send to servers have the following structure:

• The start line that specifies the HTTP method (like GET, POST, or DELETE), the target URL and the protocol version.

• Headers that pass additional info like expected format of response data, or the size and format of request data.

• (Optionally) Request body. Some request types do not use it.

Responses have a similar structure:

• The start line with the response code and message. Some frequently-used codes are 200 OK (success) and 404 Not Found (failure, the requested resource was not found).

• Headers that describe the response data format and contain additional values like cookies, server info, and so on.

• Response body, for instance, an array with requested data, an image, a file, and so on.

Frequently-used formats for request and response bodies are JSON and XML.

The command a client sends to the server for execution is called an action, method or operation depending on the service architectural style (SOAP or REST, see below).

The two popular architectural styles for web services are SOAP and REST:

• SOAP services use the SOAP protocol that is built over HTTP. These services use HTTP requests of the POST type and pass data in the XML format in request and response bodies. All the requests go to the same URL and the operation to be executed is specified by special request headers or XML elements in the request body.

  SOAP services use WSDL definitions that strictly describe operations supported by the service, their parameter types and data formats.

• REST services work over HTTP. The operation to be executed is set by a combination of the HTTP method and the requested resource name. For example, a RESTful service of an online pet store can have a /pets resource. The POST http://petstore.io/pets request can add information on a pet to the database, and the GET http://petstore.io/pets request can retrieve information on available pets.

  There are several formats of REST service definitions: OpenAPI (Swagger), WADL, and some other. However, some developers do not provide any definition for their RESTful services at all.

To ensure that a web service functions properly, you create and run functional tests on it.

These tests send requests to the server and verify its responses.

In ReadyAPI, you create functional tests in the Functional Tests node. You can easily simulate requests and customize their parameters in special editors:

Click the image to enlarge it.

To validate response data and response codes, you add assertions to test requests:

Click the image to enlarge it.

The easiest way to determine if the server is working correctly or not is to check the response code. 200 OK typically means the server processed a request successfully.

In real life, a client typically sends a series of requests to the server. For instance, for an online shop, the first request can be used for signing in, and subsequent requests – for buying some products.

In ReadyAPI, you simulate this real-life behavior by organizing requests and other test steps into test cases:

Multiple test cases that work together are grouped into test suites, which, in their turn, belong to test projects (see the image above).