RESTful Web Service Testing for beginners

What is API/Web Service Testing?

Application Programming Interface (API) is a set of rules and mechanisms by which one application or component interacts with another. API can return data in a convenient format such as JSON, XML, etc. APIs for web applications are often referred as Web services.

Testing these APIs directly as part of integration testing to determine if they meet the expectations for functionality, reliability, performance, and security is known as API Testing. API Testing can be performed manually and also with automation tools. Automated API testing is crucial for implementing testing in Continuous Integration/Continuous Deployment (CI/CD) environment.

API testing is performed at the business layer and can validate application logic. This is different than browser based Graphical User Interface (GUI) testing.

A typical three tier application

What are RESTful services?

Representational Stage Transfer (REST) is an approach and an architectural style that defines a set of constraints to be used for creating Web services. The word “Representational” means that a representation of the resources is transferred i.e. when a client request a resource, the server do not sent the actual resource, but rather a representation of that resource in a format that is readable by the client. The resources can be a list of users, pictures, documents, videos, posts, web pages, etc. that can be transferred through web. REST relies on a stateless communications protocol, most commonly, Hypertext Transfer Protocol (HTTP). REST can structure data in HTML, XML or YAML formats; however JSON is the most widely used data structure in RESTful services.

The web services that implement REST architecture are typically referred as RESTful services.

What does RESTful web services do?

RESTful services performs 4 basic operations through HTTP protocol:

  • Retrieving data – Retrieve data from the given URI
  • Create new data – Create a new entry in the database
  • Update data – Update existing entities in the server
  • Delete data – Delete a given resource at the specified URI

These operations are also called as CRUD (Create, Read, Update and Delete).

HTTP requests

In REST architecture, the client makes HTTP request to the server in order to retrieve or modify data. A HTTP request generally consists of:

  • A HTTP request method, which defines what kind of operation to perform.
  • A HTTP header, that allows the client to pass additional information about the request.
  • A request target. This is usually a Uniform Resource Locator (URL) of the resource.
  • An optional request body containing data to be sent to the server. The request body is a structured data such as XML, YAML or JSON. GET and DELETE request methods usually don’t need a message body.

HTTP request methods

The request method indicates the operation to be performed on the resource identified by the given request URI. The method should always be given in uppercase. The HTTP request methods are generally called HTTP verbs.

GET – GET method is used to retrieve data from server at the specified resource/URI. GET should only extract data and should have no other effect on the data.

POST – POST method is used to create new entity. It can also be used to send data to the web server to create or update a resource (e.g. customer information, file upload, etc. using HTML forms). The POST request requires a URI, header and a message body.

PUT – PUT method is used to send data to the API to create or update resource. The difference is that PUT requests are idempotent, meaning calling the same PUT request multiple times will always produce the same result. The PUT request requires a URI, header and the message body.

DELETE – DELETE method is used to delete the resource at the specified URI.

HTTP Response

When a client sends a valid HTTP request to the server, the server sends back the HTTP response relates to that request. The aim of the response is to inform the client that its request has been processed; or else inform the client that an error occurred in processing its request.

An HTTP response contains:

  • Status code
  • HTTP headers
  • A response body

Status code

The HTTP response from the server contain status code to inform the client about the status of its request. There are many status codes available which are grouped in five categories:

 Category Description Example
1xx: informational Communicates transfer protocol-level information 100 continue
2xx: Success Indicates that the client’s request was processed successfully 200 OK
201 Created
204 No Content
3xx: Redirection Indicates that the client must take some additional action in order to complete their request 300 Multiple choice 302 Found
4xx:
Client Error
Indicates that there is an error in the request from the client 400 Bad Request
401 Unauthorized
403 Forbidden
5xx:
Server Error
Indicates that there is a problem at the server side 500 Internal Server Error
501 Not Implemented 502 Bad Gateway

HTTP Headers

The response from the server contain different types of HTTP headers. The headers contains information that a client can use to find out more about the response, and about the server that sent it. These headers also contains information about the response body such as ‘Content-type’, ‘Content-length’, ‘Date’, etc.

Response body

For a response to a successful request, the response body contains the resource requested by the client (like content of an HTML form or a document, etc.) or some information about the status of the request. Not all responses have a body. The ‘content type’ and ‘content length’ of the body are specified in the HTTP header of the response.

For a response to an unsuccessful request, the response body might provide further information about the reasons for the error.

How to test REST API?

API testing is sending different requests to the API server and verifying the responses from the server. This is different from browser based User Interface (UI) testing. API testing requires a tool/framework that can send requests to the API and display the response from server.

There are number of open-source and commercial tools available for API testing. Postman, SoapUI, Katalon Studio and Advanced REST client are the popular open-source tools for API testing. Swagger is an open-source tool for API documentation and can also be used to validate the API endpoints.

Testing REST API with Postman

To get started, download and install latest version of Postman.

Postman landing page

Create and send HTTP Request

You can launch the Postman from the start menu or the desktop shortcut. Once the Postman is launched you can start creating the request by clicking on the new tab with + icon.

  1. Select GET request from the request method dropdown
  2. Enter the request-URL (http://httpbin.org/anything) in the URL fields
  3. Click “Send” button
GET request and response
Response headers

Verify HTTP Response

Once a successful GET request is sent to http://httpbin.org/anything, the server has sent back the HTTP response. The response contains Status-code, Header and Response body.

The status code is set to 200 OK, which means that the request was processed successfully.

The response headers contains information about the response body such as:

  • Content-Type: application/json – indicates that the data in the response body is in JSON format.
  • Date – date and time the message was sent.
  • Content-Length: 279 – indicates the size of the data in the response body

The response headers also contains other information that is required by the client to process and display the response to the user.

The response body contains the resource requested by the client from the given URL. In this case the response body is some data presented in JSON format.

Read more about using Postman for API testing here.

API Testing Mind map

API testing mind map

Happy testing!

Published by Venu Botla

A passionate QA Automation test consultant helping organisation to implement QA process in Agile teams, integrating testing at each stage of the software development life cycle and preparing automation test strategy to support CI/CD pipelines. Over 9 years working alongside customers to understand their businesses and technology challenges as part of a specialist team that ensures projects are a success. Experienced in developing test automation frameworks to support releases with CI/CD pipelines, implementing QA best practices and leading QA teams within the public, private and third sectors. Special interest in making web application more accessible and passionate about learning new testing tools and technologies.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: