In recent years, Representational State Transfer (REST) has become a dominant model for software architecture, especially for Web-based applications. Today, most large websites and Web applications on the Internet have REST APIs. Some examples of websites using REST APIs include Twitter, Google, Flickr and so on.
The great thing about a REST API is that it is usually well-defined and therefore allows clear separation between the client logic and the server logic. This property in itself is very beneficial for both functional and load testing of the application server. In the following article we will demonstrate an easy way to test your application’s REST API using HP LoadRunner’sweb_custom_request method.
REST API Basics
Before we dive into load testing, let’s look at the basic terminology of a REST API. A REST API call consists of three major components:
The Uniform Resource Identifier (URI) – This is a string which consists of three parts. The first part contains the host (and optionally, the port) of the API call (e.g. http://www.hp.com). The second part contains the path which identifies the call functionality. This path can include some parameter values although they are distinguishable from the constants only by semantics (e.g. /users/megwhitman/type/ceo, where “megwhitman” and “ceo” are parameters while “users” and “type” are constants). The third part is the QueryString which is a list of key-value pairs (e.g. user= megwhitman & type=ceo). The pairs are separated by the “&” sign and the entire QueryString is separated from the path by the “?” sign. A full URI may look something like this: http://www.shopping.hp.com/en_US/home-office/-/products/Tablets/Tablets?SearchParameter=ElitePad
The verb – The verb can be any word describing the operation you want to perform on the URI. In HTTP, the five most commonly used verbs are: GET, POST, PUT, DELETE, and PATCH. Note that the operation for each verb is determined by the server although there are some common conventions in this area.
The payload (data) – This is the data sent to the server with the request. For example, if we want to save a text file to the server, we can send the content of the text file as the payload.
Test Case
The example application under test is a todoMVC application which manages a ‘todo’ list. This application has a REST API, as follows:
/todos, GET, No Payload – Retrieves all the todos currently in the list
/todos, POST, { isFinished :, todoText: } – Creates a new todo on the server with the text provided in the payload by the parameter.
/todos/, PUT, {id:, todoText: , isFinished:< isFinished>} – Updates the todo with id with the text and finished state < isFinished>
Note that all the data passed to and received from the server is in the JavaScript Object Notation (JSON) format which is gradually becoming the standard format for data transfer.
HP LoadRunner allows us to easily simulate HTTP calls through the web_custom_request function. We want to simulate a business process as follows:
1) Get the existing todos from the server
2) Add two new todos
3) Update the last todo added with a new text
Step 1
We use recording to ‘learn’ this step. In VuGen we create a new Web - HTTP/HTML script and record a browser opening the todoMVC application. When the application starts, it gets all the todos currently stored on the server through the GET API call. We can easily find the correct step in the recorded script by looking at the URL argument. In this case the argument is - "URL=http://localhost:3000/todos" (since the application is running locally on port 3000 on my machine). The relevant step is:
web_custom_request("todos",
"URL=http://localhost:3000/todos",
"Method=GET",
"Resource=1",
"RecContentType=application/json",
"Referer=http://localhost:3000/",
"Snapshot=t66.inf",
LAST);
The “Method” argument is the REST verb (GET in this case), and the “Snapshot” argument links to the correct snapshot file on the disk. The snapshot of this step can be viewed in the Snapshot Viewer:
We can see that the response from the server is a list of all the todos presented by our application in JSON format.
Step 2
Adding a new todo is very simple. We create our own web_custom_request step with the parameters required by thePOST REST API. The created step looks something like this:
web_custom_request("Add Todo",
"URL=http://localhost:3000/todos",
"Method=POST",
"Resource=0",
"EncType=application/json",
"Mode=HTTP",
"Body={\"isFinished\":false,\"todoText\":\"This is VuGen\"}",
LAST);
A few things to notice here:
1) The “Method” (verb) is POST as required by the REST API.
2) We specified the “EncType” parameter to inform the server that the payload is going to be in JSON format.
3) We added our payload to the “Body” parameter in JSON format.
Since writing the JSON in the middle of the script may be a bit cumbersome, we can add it as an extra file to the script. To do this simply right-click the “Extra Files” node in the Solution Explorer and select “Add Files to Script…”, and choose the data.json file we prepared earlier. On a fresh installation of LoadRunner you may need to specify the .json extension as a valid extension for extra files. You can also do this after adding the file to your script. In VuGen, select Tools > Options > Scripting > Script Management and add the .json extension to the Allowed Extensions list. Once the file is added, the project looks something like this:
Now we can add the file as our payload by specifying the BodyFilePath parameter:
The great thing about a REST API is that it is usually well-defined and therefore allows clear separation between the client logic and the server logic. This property in itself is very beneficial for both functional and load testing of the application server. In the following article we will demonstrate an easy way to test your application’s REST API using HP LoadRunner’sweb_custom_request method.
REST API Basics
Before we dive into load testing, let’s look at the basic terminology of a REST API. A REST API call consists of three major components:
The Uniform Resource Identifier (URI) – This is a string which consists of three parts. The first part contains the host (and optionally, the port) of the API call (e.g. http://www.hp.com). The second part contains the path which identifies the call functionality. This path can include some parameter values although they are distinguishable from the constants only by semantics (e.g. /users/megwhitman/type/ceo, where “megwhitman” and “ceo” are parameters while “users” and “type” are constants). The third part is the QueryString which is a list of key-value pairs (e.g. user= megwhitman & type=ceo). The pairs are separated by the “&” sign and the entire QueryString is separated from the path by the “?” sign. A full URI may look something like this: http://www.shopping.hp.com/en_US/home-office/-/products/Tablets/Tablets?SearchParameter=ElitePad
The verb – The verb can be any word describing the operation you want to perform on the URI. In HTTP, the five most commonly used verbs are: GET, POST, PUT, DELETE, and PATCH. Note that the operation for each verb is determined by the server although there are some common conventions in this area.
The payload (data) – This is the data sent to the server with the request. For example, if we want to save a text file to the server, we can send the content of the text file as the payload.
Test Case
The example application under test is a todoMVC application which manages a ‘todo’ list. This application has a REST API, as follows:
/todos, GET, No Payload – Retrieves all the todos currently in the list
/todos, POST, { isFinished :
/todos/
Note that all the data passed to and received from the server is in the JavaScript Object Notation (JSON) format which is gradually becoming the standard format for data transfer.
HP LoadRunner allows us to easily simulate HTTP calls through the web_custom_request function. We want to simulate a business process as follows:
1) Get the existing todos from the server
2) Add two new todos
3) Update the last todo added with a new text
Step 1
We use recording to ‘learn’ this step. In VuGen we create a new Web - HTTP/HTML script and record a browser opening the todoMVC application. When the application starts, it gets all the todos currently stored on the server through the GET API call. We can easily find the correct step in the recorded script by looking at the URL argument. In this case the argument is - "URL=http://localhost:3000/todos" (since the application is running locally on port 3000 on my machine). The relevant step is:
web_custom_request("todos",
"URL=http://localhost:3000/todos",
"Method=GET",
"Resource=1",
"RecContentType=application/json",
"Referer=http://localhost:3000/",
"Snapshot=t66.inf",
LAST);
The “Method” argument is the REST verb (GET in this case), and the “Snapshot” argument links to the correct snapshot file on the disk. The snapshot of this step can be viewed in the Snapshot Viewer:
We can see that the response from the server is a list of all the todos presented by our application in JSON format.
Step 2
Adding a new todo is very simple. We create our own web_custom_request step with the parameters required by thePOST REST API. The created step looks something like this:
web_custom_request("Add Todo",
"URL=http://localhost:3000/todos",
"Method=POST",
"Resource=0",
"EncType=application/json",
"Mode=HTTP",
"Body={\"isFinished\":false,\"todoText\":\"This is VuGen\"}",
LAST);
A few things to notice here:
1) The “Method” (verb) is POST as required by the REST API.
2) We specified the “EncType” parameter to inform the server that the payload is going to be in JSON format.
3) We added our payload to the “Body” parameter in JSON format.
Since writing the JSON in the middle of the script may be a bit cumbersome, we can add it as an extra file to the script. To do this simply right-click the “Extra Files” node in the Solution Explorer and select “Add Files to Script…”, and choose the data.json file we prepared earlier. On a fresh installation of LoadRunner you may need to specify the .json extension as a valid extension for extra files. You can also do this after adding the file to your script. In VuGen, select Tools > Options > Scripting > Script Management and add the .json extension to the Allowed Extensions list. Once the file is added, the project looks something like this:
Now we can add the file as our payload by specifying the BodyFilePath parameter:
web_custom_request("Add Todo from file",
"URL=http://localhost:3000/todos",
"Method=POST",
"Resource=0",
"EncType=application/json",
"Mode=HTTP",
"BodyFilePath=data.json",
LAST);
Step 3
We want to update the last todo with some new values. To do this, we use another web_custom_request with the PUTverb as specified by the REST API. This is very similar to the step that adds a new todo:
web_custom_request("Update Todo",
"URL=http://localhost:3000/todos/3",
"Method=PUT",
"Resource=0",
"EncType=application/json",
"Mode=HTTP",
"Body={\"id\":3, \"isFinished\":false,\"todoText\":\"Updated the name\"}",
LAST);
This command updates the todo with id = 3 with the string “Updated the name”.
As with the previous step, you can manage the JSON text as a file, rather than writing it directly into the script.
Conclusion
We’ve seen how easy it is to create a simple load test with a REST API using HP LoadRunner. The web_custom_requestfunction is versatile enough to cover both simple and complex cases, thus simplifying REST API testing.
"URL=http://localhost:3000/todos",
"Method=POST",
"Resource=0",
"EncType=application/json",
"Mode=HTTP",
"BodyFilePath=data.json",
LAST);
Step 3
We want to update the last todo with some new values. To do this, we use another web_custom_request with the PUTverb as specified by the REST API. This is very similar to the step that adds a new todo:
web_custom_request("Update Todo",
"URL=http://localhost:3000/todos/3",
"Method=PUT",
"Resource=0",
"EncType=application/json",
"Mode=HTTP",
"Body={\"id\":3, \"isFinished\":false,\"todoText\":\"Updated the name\"}",
LAST);
This command updates the todo with id = 3 with the string “Updated the name”.
As with the previous step, you can manage the JSON text as a file, rather than writing it directly into the script.
Conclusion
We’ve seen how easy it is to create a simple load test with a REST API using HP LoadRunner. The web_custom_requestfunction is versatile enough to cover both simple and complex cases, thus simplifying REST API testing.
