Web Services

A web service is a unit of managed code that can be remotely invoked using web protocols. This allows you to share your application’s functionality with other programs. Rapise provides native support for testing web services. Web service tests can be integrated with user interface tests for complete coverage.


The purpose of Web Service testing is to verify that all of the Web Service APIs published by your application operate as expected. Web Service API testing requires that you test using all the expected data formats and input parameters.

There are two broad classes of web service:

  • SOAP - These web services make use of the Web Service Definition Language (WDSL) and communicate using HTTP POST requests. They are essentially a serialization of RPC object calls into XML that can then be passed to the web service. The XML passed to the SOAP web services needs to match the format specified in the WSDL. SOAP web services are fully self-descripting, so most clients do not directly work with the SOAP XML language, but instead use a client-side proxy generator that creates client object representations of the web service (e.g. Java, .NET objects). The web service consumers interact with these language-specific representations of the SOAP web service.
  • REST - A RESTful web API (also called a RESTful web service) is a web API implemented using HTTP and REST principles. Unlike SOAP-based web services, there is no "official" standard for RESTful web APIs. This is because REST is an architectural style, unlike SOAP, which is a protocol. Typically REST web services expose their operations as a series of unique "resources" which correspond to a specific URL. Each of the standard HTTP methods (POST, GET, PUT and DELETE) then maps into the four basic CRUD (Create, Read, Update and Delete) operations on each resource. REST web services can use different data serialization methods (XML, JSON, RSS, etc.).

Testing REST Web Services

When you add a web service to your Rapise test project, you get a new REST definition file (.rest) that will store all of your prototyped requests against a specific REST web service. The various REST requests are then created in the REST definition builder:

Rapise’s query builder streamlines the testing of your APIs with robust debugging and message tracing.

Once you have finished with your prototyping of the web service test operations, you can then save the request definitions and use the ‘Update Object Tree’ and ‘Create Script’ options to populate the main Rapise Object Tree and generate a working test script in JavaScript:

Each of the REST service objects in the tree has operations designed to let you call the method and access the returned body either in its raw text format, or if it's a web service that returns data in JSON format, it will be able to send/receive data as native JavaScript objects.

Once all the REST operations have been defined and saved as Rapise learned objects, you can call the REST operations from within your Rapise test scripts:

As well as simply calling the DoExecute() method of each REST web service object to call the previously defined operation, you can use the various properties on the REST service object to send through specific parameter values, add/remove headers, change the authenticated user, change the request body as well as inspect all of the attributes in the request and response.

This allows you unparalleled control over the web service request, with the ability to debug and diagnose web service issues in addition to being able to quickly call the learned operations.

Since the REST objects are just like any other Rapise object, you can have hybrid test scripts that call web service methods and also test GUI objects. This is very useful when you want to test how the user interface changes in response to specific web service API interactions, or when you have a user interface that connects to the sever using a web service (for example with a JSON-based AJAX web user interface).

Testing SOAP Web Services

When you add a SOAP web service to your Rapise test project, you get a new SOAP definition file (.soap) that will store all of the test invocations against a specific SOAP web service:

The SOAP test studio works by connecting to the WSDL location that you specify in the Endpoint tab. Rapise will download the WSDL file and display the list of available methods in the SOAP explorer. You can now navigate all the exposed operations and send test requests through to the SOAP endpoint and verify that the results are correct.

You can also click on the Request/Response tab to view the raw SOAP XML that was sent to and from the server. This is very useful when debugging a service that does not work as expected:

To save time, Rapise can generate the test script code automatically for you (instead of having to write it by hand). It does this by recording the operations you have tested and captured the expected results of a successful operation:

When you have finished your testing session, you can click the ‘Create Script’ option and Rapise will generate the appropriate test script automatically, using the saved objects. You can now playback the tests to regression test your API:

Try Rapise free for 30 days, no credit cards, no contracts

Start My Free Trial

And if you have any questions, please email or call us at +1 (202) 558-6885