REST API Automation

Owned by Joseph Hamdan
Last updated: Jun 21, 2024
7 min read

 

Introduction

A REST (Representational State Transfer) API is an architecture that allows systems to communicate with each other. In REST, everything is a resource and REST API is commonly used for web services and allows clients to interact with resources on a specific server using HTTP Methods (verbs). The following are most commonly used Methods:

GET: Retrieves a resource or a group of resources

POST: Creates a new resource

PUT / PATCH: Updates an existing resource or creates a new one

DELETE: Removes a resource

 

Endpoints: An API endpoint is a specific URL where a resource or a group of resources can be accessed. Each endpoint corresponds to a different action or operation on the resource. For example, /profiles could be the endpoint to retrieve all profiles, and /profiles/{id} could be the endpoint to retrieve a specific profile by its ID.

 

When a client makes a call to a REST API, it sends an HTTP request to a specific endpoint, including the desired HTTP method, headers, and possibly a request body. The server then processes the request and sends back an HTTP response, which includes a response status code, headers, and a response body (if available).

 

HTTP Status Codes are numbers included in the response that indicate the status of the request. Some commonly used status codes for REST APIs include:

  1. 200 (OK): The request was successful

  2. 201 (Created): A new resource was successfully created

  3. 400 (Bad Request): The request is malformed or has invalid data

  4. 401 (Authorization): The request is not authorized

  5. 404 (Not Found): The requested resource is not found

  6. 415 (Unsupported Media Type): The server cannot process the request because the media type or format of the request is not supported (header may be required)

  7. 500 (Internal Server Error): An error occurred on the server

These codes help the client understand the outcome of their request and handle any errors or exceptions.

 

Authorization

  1. Basic Authorization: a simple authorization where the client sends the username and password which are typically encoded in Base64 format. The server then decodes the credentials and verifies them against a user database. If the credentials are valid, the server grants access to the requested resource.

  2. Digest Authorization: a more secure method of authorization compared to basic authorization. It involves a challenge-response mechanism where the server generates a unique nonce (number used once) and sends it to the client. The client then uses the nonce to generate a hash code using a specified algorithm. The client sends this hash code in the Authorization header back to the server. The server performs the same calculation using the stored credentials and checks if the hash code matches, after which the server grants access to the requested resource.

  3. NTLM Authorization: an authorization protocol used in Microsoft Windows environments. It is commonly used for integrating REST APIs with Windows Active Directory (AD) for authorization. The client’s Workstation and Domain are typically required for the authorization process.

 

Headers provide additional information about the request or response. They consist of key-value pairs and are included in the HTTP request or response message. Here are the most commonly used headers in REST APIs:

  1. Content-Type: specifies the media type of the request or response body, such as JSON (application/json) or XML (application/xml).

  2. Accept: indicates the media types that the client can accept in the response.

  3. Authorization: used to authenticate the client's credentials. It contains the authentication token or credentials required for accessing protected resources.

  4. X-API-Key: similar to Authorization header and it contains an API key, which is a secret token provided by the API provider to the client. The API key acts as a unique identifier for the client and is used to authenticate and authorize the client to access protected resources or perform specific actions within the API.

PS: In Subject7, you can also add you own header name in case it’s not one of the available options.

Subject7 Setup

  1. In order to begin automating REST APIs, you will first need to create a REST Connection. Hover over Repository menu and select REST Connections

  2. Click + and select Connection

  3. Insert a name for your REST Connection

  4. Insert the URL of the endpoint in URL field

  5. If your API call requires authorization, select the Type and enter the credentials.

  6. Under Method section, select the method for your request

  7. As an example, we will use an endpoint which will allow us to send an execution set to cloud run.

  8. If you select POST, PUT, PATCH or DELETE, you can enter Payload if it’s required. GET method does not have a payload because it has no meaning to the server

    { "name": "api_test", "configuration": { "pool": "default", "buildNumber": "10.2.3.2217", "browserTypes": [ "CHROME" ], "videoCaption": true, "delay": 10, "rotations": 1, "runtimeSpeed": 200, "callbackArgs": null, "dataSetSelection": [], "projectName": "Common", "versionName": "default", "dataTemplateFieldValueReplacements": [] } }

  9. In order to test your API call before using it in a test case, click Test Connection next to Configuration

  10. Click Test Connection button

  11. As you can see in the screenshot above, the test was successful as shown by the Status Code = 201 (execution set was created)

  12. The Response Headers section will display all headers associated with your request, including the date in which your request was completed

  13. The Loading Time displays how much time communication spent to finish the request in milliseconds

  14. The Response (or body) displays the response sent back by the server which shows that an execution set was sent to be executed in the cloud.

  15. Back on the platform, you can go to Execution Sets under Executions menu, find the execution set “api_test” and check the request you sent. As you can see below, the information matches what we specified in the payload and the id matches what was sent back in the responses. If you see Web Service under Type, this indicates that the request was sent via a REST API. Additionally, the Build Number can be used in special CI/CD pipelines to indicate against which build your API request was executed.

     

Using Subject7 Commands

  1. In order to integrate the REST Connections into your test cases, you can use the following commands:

    1. Execute_REST: Used if you want to execute a request without retrieving any data back from the response/headers. For example, uploading datasets into a data template.

    2. Get_REST_Value: Used if you want to execute a request and receive some data back from the response/headers. For example, sending an execution set to cloud run and getting the id and state from the response.

    3. Verify_REST: Used if you want to verify specific data exists in the response/headers. For example, verifying that the state is CREATED.

 

  1. Execute_REST: This command requires only the Status Variable which will be used to store the returned http status code into this variable and the REST Connection.

  1. Get_REST_Value: This command requires the following options:

    1. Status Variable: used to store the returned http status code into this variable

    2. Capturing Variable: used to store the returned values from the response/headers which correspond to each Key/XPath provided by the user. If more than one Key/XPath is specified, the variables should be separated with commas.

    3. Keys/XPaths: indicates what you want to receive from the response/headers by specifying the key that you see in the response. The Type of data to receive will also need to be determined. You can select from the below options:

      1. HEADERS: to retrieve a value in the headers section

      2. BODY_JSON: to retrieve a value in the body using a specific Key/XPath

      3. BODY_JSON_COUNT: to return the count of elements in the response that correspond to a Key/XPath in JSON

      4. BODY_XML: to return the entire body in XML

      5. BODY_XML_COUNT: to return the count of elements in the response that correspond to a Key/XPath in XML

      6. BODY_TEXT: to return the entire body in JSON

    4. REST Connection

  2. Verify_REST: This command requires the following options:

    1. Status Variable: used to store the returned http status code into this variable

    2. Value: indicates what you want to compare from the response/headers against another value of your choosing. The Operator Type will need to be selected from one of these options:

      1. EQUALS: Checks whether a value in the response/headers equals the value of your choosing

      2. NOT_EQUALS: Checks whether a value in the response/headers does not equal the value of your choosing

      3. CONTAINS: : Checks whether a value in the response/headers contains the value of your choosing

      4. COUNT: Counts elements in the response/headers and compares against a number of your choosing

Using Subject7 APIs

You can use Subject7 APIs which can be accessed in this URL to automate various actions on your account. Here are some examples:

  1. POST/executions: Allows you to send an execution set to the cloud run

  2. POST​/test-case-executions: Allows you to send a test case to cloud run independently (same as clicking Cloud Run icon on any test case)

  3. POST​/load-plan-executions: Allows you to load run a load set in cloud

  4. PUT​/load-plan-executions​/{id}: Allows you to cancel a load run by specifying the id of that run