What is API and REST Architecture in the Context of Software Testing?

Source: Medium

API API is an abbreviation for Application Programming Interface. It is a collection of programming code and protocols which enable data transfer via JavaScript Object Notation (JSON) or Extensible Markup Language (XML) format between one software product with another product or service. API allows interaction with the software surpassing the graphical user interface. API testing allows the tester to make requests that might not be allowed through the UI, which is crucial for exposing potential security flaws in an application. Therefore, testing of API allows the tester to find bugs earlier in the development process, often before the UI has been created.

APIs considerably simplify the app development, save software programming and testing time, efforts, moreover at the early stage of the app development simplifying the design. APIs simplify how developers introduce new application components into the architecture of the software, help businesses and IT teams to collaborate. They are considered as “contracts” containing documentation, so-called “agreements” between parties: for example if a client sends a remote request structured in a particular way, this is how the server or another software will respond to that request. In particular, APIs can be used to create, retrieve, update or delete data in an application’s database using CRUD operations.

What is the REST API?

REST stands for “Representational State Transfer”. REST represents the rules that developers follow while creating APIs. REST was firstly introduced by Roy Fielding in 2000. It has the following criteria and constraints for RESTful web services:

• Client-Server. The client makes an HTTP request to a URL hosted by a server, which returns, in its turn, a response as an HTML page. This procedure is analogous to the work of a browser.
• Stateless. Every HTTP request is implemented in isolation from one another. When the client makes an HTTP request, it includes all information necessary for the server to respond to that request. The server does not save any data/information from previous requests.
• Cacheable. Storing data/information used repetitively in local memory so that every time the client requests this information, instead of retrieving the information from the database, the information from the local memory is retrieved.
• Layered. There are a number of layers in API server architecture. Each request must travel through each of the layers before reaching the API implementation.

How to create a RESTful Web Service?

A RESTful web service request contains:

An Endpoint URL. An application implementing a RESTful API will outline the URL endpoint, including a domain, port, path, and/or query string.

CRUD HTTP methods. Used on any endpoint to perform “create”,” read”, “update”, and “delete” (CRUD) operations.

Examples:

• a GET request to /user/ returns a list of registered users on a system
• a POST request to /user/4545 creates a user with the ID 4545 using the body data
• a PUT request to /user/4545 updates user 123 with the body data
• a GET request to /user/4545 returns the details of user 4545
• a DELETE request to /user/4545 deletes user 4545

HTTP headers can provide information to the server such as:

• The Host: the domain and port number of the client making the request
• Authorization: the credentials (token) of the user making the request
• The Content-Type: the format of the information provided in the body of the request

What is a “request body”?

The request body outlines what specific data/information must be added to the database and used in the course of making POST, PUT, or PUT / PATCH requests. The body usually is in JavaScript Object Notation (JSON) or Extensible Markup Language (XML) format.

For example, here is a JSON request body for a POST request (adds a customer to a database):

{

“firstName”: “Ann”,

“lastName”: “Jones”,

“emailAddress”: “ajones@example.com”

}

Full knowledge of the components of the REST request will help software testers send and interpret the response of the requests for testing purposes.

What Is the Response to a REST Request?

The response to a REST request is the data fetched from the server in correspondence with the request sent. It includes HTTP headers, a response code, and a response body.

In the response, the HTTP headers provide information such as:

• Access-Control headers: inform the client of what types of requests and headers will be permitted
• The Content-Type: the format of the information returned in the response
• The Server: the name of the server used to fetch the data

What are response codes?

The ultimate result of the REST request is displayed with the help of response codes which are three-digit codes. For example:

• 200-level response means the request was received and processed successfully
• 400-level response means the request was received, however, there was an error in the client’s input
• 500-level response means the server used for fetching the data encountered some problems/errors.

How Can We Test APIs?

Firstly, the tester needs to analyze which of the REST requests should be performed by the API and what are the possible drawbacks of each of those. The official documentation, for example, Swagger, is an open-source blueprint framework that specifies the API’s behavior.

It’s important to find, test, and verify those limitations to ensure that the API will behave in an expected way and that it cannot present a gateway for malicious users to access sensitive/private information.

The second step is to set up each of these requests in an API test tool, such as Postman.

For testing purposes, the first requests to set up should be the “happy path” requests, which are the expected behavior of the requests and responses from the server that users would make in the normal course of using the application. For example,

• Sending a request with the correct HTTP verb
• Sending a request with the correct endpoint
• Sending a request with the correct headers
• Sending a request with the proper authorization (token)
• Requesting data for a record that exists
• Sending a request with a correct body information

Testers should use negative tests to ensure that errors are handled appropriately. The most important criteria are to ensure that when the user supplies invalid data, the application doesn’t crash. Some examples of negative tests are :

• Sending a request with the wrong HTTP verb
• Sending a request with the wrong endpoint
• Sending a request with the wrong headers
• Sending a request with missing headers
• Sending a request without the proper authorization
• Requesting data for a record that does not exist
• Sending a request with a body that has missing required fields
• Sending a request with a body that has invalid field values, etc.

I have tried to help the learners to acquire some introductory knowledge about REST APIs. I hope you’ve found this article useful, and please feel free to share a comment below!