Testing REST Web Services

What is REST and what is a RESTful web service?

REpresentational State Transfer (REST) is a style of software architecture for distributed systems such as the World Wide Web. REST has emerged as a web API design model that offers greater simplicity over other web service protocols such as SOAP and XML-RPC.

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.

How does Rapise test REST web services?

Creating a REST web service test in Rapise consists of the following steps: 1. Using the REST definition builder to create the various REST web service requests and verify that they return the expected data in the expected format.

  1. Parameterizing these REST web service requests into reusable templates and saving as Rapise learned objects.

  2. Generating the test script in Javascript that uses the learned Rapise web service objects.

Rapise REST Definition Builder

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:

rest_definition_editor

Each REST request can then include the following items:

When you execute the request, it will return back the HTTP response headers and if it recognizes the MIME content-type as either XML or JSON, it will format it to make it more readable by the tester:

rest_definition_request

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 option to populate the main Rapise Object Tree.

Web Service Object Recognition

Each of the REST web service requests that has been prototyped in the REST definition editor is converted by Rapise into a scriptable object:

Web Service Objects

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.

Rapise provides you with access to the following attributes of the HTTP request before/after the request has been executed:

Generating Rapise REST Test Scripts

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.

The easiest way to do this is to click on the Record button in the REST definition editor (next to the Send button) which will add the request to list of recorded steps:

rest_script_steps

Usually you need to verify the data returned as well as call the REST method. To do this, go to the Verify text box underneath the Body section:

clip0155

If you select the overall array response[14] and click the main Verify button next to the Record button, the system will automatically add a verification step that verifies all of the values. To try this, click the Verify button. This will add a bold verification step to the recorded script:

clip0156

You will see a script step recorded with a verification test added (it's shown in bold with an asterisk*).

However, in many cases you only want to verify certain properties. For example, we might want to just verify that 14 books are returned, and that the first book has the right name. To do this, right-click on the response[14] entry to display the verification content menu:

clip0157

Choose the option Verify Response length=14. This adds the following step to the recorded script:

clip0158

Now we want to verify the name of the first book returned. To do that, expand the “0” index entry and then right-click on the “Name” property returned:

clip0159

Choose the option to Verify Repsonse[0].Name = Hound of the Baskervilles. This will add a verification step for this specific property:

Verify Name

Once you are ready, click the Create Script and the test script will be created for you:

Created Script

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

rest_hybrid_test

Once you have created your REST web service test, you can use the standard Playback functionality in Rapise to execute your test and display the report:

tutorial_web_services_pic30

Handling File Uploads and Multipart Requests

Each Request with Content-Type set to multipart/form-data is assumed to be a special request and handled in a special way.

The Body part should be a valid JSON with the following structure:

{
    "multipart":
    [
        {
            "Name": "name_of_text_field",
            "ContentType": "text/plain",
            "Value": "value"
        },
        {
            "Name": "uploadfile",
            "ContentType": "image/png",
            "FileName": "image.png",
            "FullPath": "path_to_file_for_upload"
        }
    ]
}

WS Multipart

For the text fields ContentType is optional. By default is is set to text/plain.

For file upload fields ContentType and FileName are optional. By default content-type and FileName are auto-detected form the FilePath.

So here is an example of the minimal multipart request with one text field and one file upload:

{
    "multipart":
    [
        {
            "Name": "name_of_text_field",
            "Value": "value"
        },
        {
            "Name": "uploadfile",
            "FullPath": "c:\\some\\path\\to\\image.png"
        }
    ]
}

JSON as Field Value

Here is how you can pass JSON value of the field:

{
    {
      "Name": "jsonText",
      "ContentType":"text/json",
      "Value": {
        "One":"Value1",
        "Two":123
      }
    },
    ...
  ]
}

Params in Multipart Request

It is typical that you want to parameterize text value or file path. It is important to make sure that you properly quote custom value. I.e.

If we have a parameterized JSON Body:

{
  "multipart": [
    {
      "Name": "jsonText",
      "ContentType":"text/json",
      "Value": {StringParam}
    },
    {
      "Name": "uploadfile",
      "FilePath": {FilePathParam}
    }
  ]
}

WS Multipart

Once parameters are defined for the multipart request, you should make sure that they are properly escaped. Consider using JSON.stringify appropriately, i.e.:

RestMultipart_UploadFileParams.SetParameters('StringParam', JSON.stringify("Some Value"));
RestMultipart_UploadFileParams.SetParameters('FilePathParam', JSON.stringify( Global.GetFullPath('NewAvatarImage.png') ));