Imagine, for a moment, that a stranger approached you and said: “I have a solution for all your problems and you will never have to worry again in your life!” I am quite sure your answer would’ve been a definite “Yes!!!” and your story would’ve had a generic happy ending. Well, I can’t promise to solve all your problems, I can’t promise that you’ll never ever have to worry again, but what I can do is to offer you something that could make your life easier and your testing job more bearable. It could also make you a better tester.

In short, this miraculous thing is called API (Application Programming Interface) testing. It’s described by Wikipedia as “a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security”. Speaking in a simpler (and probably less accurate) manner, it’s testing with no UI.

In this article, I will focus mostly on testing REST API (Representational State Transfer API), “an architectural style and an approach for communication user in the development of Web services” (see https://www.guru99.com/testing-rest-api-manually.html). Why REST API? Because it’s, arguably, the most popular approach nowadays. Moreover, I will use JSON as preferred content type and Postman app as a tool of choice, but it’s important to emphasise that they are not the only options. However, they might be the most practical at the moment.

The article will be divided in two parts. Part one, which you are currently reading, will mostly focus on the benefits of API testing and on HTTP and JSON basics. Part two will focus on how we’ve implemented this knowledge to create an automated API testing environment in Postman.

Note that we will be dealing here with the basic API testing stuff, so if you’re an experienced user, this might be a little too basic for you. The article is mostly oriented towards the automation beginners, or people who haven’t had much or any experience in API testing.

Why we did it

Okay, so what’s all the fuss about? Why add more work to the test workflow? Well, benefits of API testing can be divided in two main points: 1. Tester is likely to have less bugs when testing UI; 2. Tester can understand and communicate bugs much better to developers. Certainly, there are other benefits of API testing, but I find these two the most important ones.

Let’s explain these points. First of all, API testing can be done while frontend is still being developed, taking into account that the whole backend logic for a given entity has already been done. Basically, one can test the elementary business logic of the app before even looking at the UI. This means that UI will probably have less logic-oriented bugs, which means less work for both the tester and the developer. It also means that the tester will get to understand the logic behind the UI much better from the word go.

Second point refers to the required knowledge of HTTP and JSON which the tester should acquire. Understanding HTTP status codes (we will explain this later) and JSON objects can help tester understand what’s wrong with the app, whether it’s a frontend or backend issue, and communicate the problem to the developers more efficiently. This way, there is less uncertainty and confusion in the development workflow.

You may not agree with me about this. That is okay, not everyone will benefit from API testing the same way (it depends a lot on the nature of the project you’re working on), but one should, in any case, at least try and see what happens. It just might be the thing that you’ve been looking for.

HTTP basics

“HTTP (Hypertext Transfer Protocol) is designed to enable communications between clients and servers. HTTP works as a request-response protocol between a client and server. A web browser may be the client, and an application on a computer that holds a web site may be the server” (see https://www.w3schools.com/tags/ref_httpmethods.asp).

This definition is perhaps the simplest one. It describes, in the most basic sense, everything a tester needs to know about basic HTTP logic for API testing. As mentioned, HTTP works as a request-response protocol between two parties. This means that we need some standardised “language” of communication between them, right?

That’s where METHODS come into play. Methods are different sorts of requests made by the client to the server, which then returns a response to the client. These methods are what frontend uses to communicate with the backend, therefore most of the UI logic that you see can also be covered via API tests. There are four main methods which are considered to be the most important and used ones in REST architectural style: GET, POST, PUT and DELETE.

GET – The GET method is pretty self-explanatory; it enables you (the client) to get some information from the server. For example, let’s say you go to the market store and you want to buy some apples. You approach the shop clerk and ask him to show you some red apples. He returns with the apples and shows them to you. This is how GET method works, it shows you a collection of specific objects available on the server. Note that this method only extracts the data, it should not have any other function or effect on the data.

POST – The POST method means you’re creating a new entity in the server database or perhaps sending some data to the server. For example, let’s say you want to give some red apples to the market store. You come to the store, give them to the clerk and your apples become part of the collection. Now, if you use GET method, you will be able to see both your apples and the apples that have been added to the collection previously.

PUT – The PUT method is used for updating the existing entity on the server, but can also be used for creating a new one (like POST method). We can describe this with market store example as well – you come to the market store, take one apple from the collection and then update one of its properties, such as size or similar. If you use GET method, you will get the apple with its updated properties.

DELETE – The DELETE method is perhaps the simplest one – it deletes something from the server, that is, it removes an apple, or multiple apples, from the collection.

By now, you probably wonder – well, how do I actually send these methods? Well, methods are sent to the server via so-called API endpoints, described as “one end of a communication channel” (see https://smartbear.com/learn/performance-monitoring/api-endpoints/). To be more precise, it’s a URL on the server, an address, where resources and their implemented logic are residing. Your “apple endpoint” may look something like this: http://testsite.com/api/apples. So, if you want to do something with the apples, you send your request to this specific endpoint.

We’ve already mentioned the importance of understanding HTTP status codes in testing workflow, both API and UI. HTTP status codes are codes which are attached to the server’s response to the client. Server response depends upon them, that is, they signify what server “thinks” about your request. For example, if you send a valid request to the server, server will respond with the correct response. However, if your request is not valid, server may return something completely different and notify you about what’s wrong with your request. HTTP status codes are categorised in five numeric categories:

• 1xx (Informational): The request was received, continuing process
• 2xx (Successful): The request was successfully received, understood, and accepted
• 3xx (Redirection): Further action needs to be taken in order to complete the request
• 4xx (Client Error): The request contains bad syntax or cannot be fulfilled
• 5xx (Server Error): The server failed to fulfill an apparently valid request

For example, if your GET request is valid, server will return you status code 200 OK, which means – everything’s okay, here’s what you asked for. If you send a valid POST request, server will respond with 201 Created status code, which means that new entity has been created successfully.

On the other hand, if you try to GET a non-existent entity or endpoint, you’re likely to get 404 Not found status code, which means that the requested resource cannot be found at the moment. You may also get 400 Bad request status code, which means that your request is not valid (e.g. malformed request syntax, size too large, etc.).

Now that you understand how HTTP status codes are categorised and how they function, you can look for more of them. If you want to see full list of status codes and their meaning, please see Wikipedia article (https://en.wikipedia.org/wiki/List_of_HTTP_status_codes).

JSON basics

JSON (JavaScript Object Notation) is defined as “an open-standard file format that uses human-readable text to transmit data objects consisting of attribute values pairs and array data types” (see https://en.wikipedia.org/wiki/JSON). In other words, JSON file contains objects and their properties, along with the property values. Basic JSON object with its properties would look something like this:

As you can see, it has certain attributes and each of those attributes have a certain value. Also, each object is enclosed in curly braces. If the JSON file has multiple objects, they might be enclosed in square brackets as array. JSON file syntax is, quite obviously, pretty simple and easy to remember, so anyone can start working with JSON pretty quickly.

Nowadays, most of the communication between client and server nowadays is done via JSON files, which is the reason I’ve chosen it as my “preferred weapon” in the article. If you take into account everything that’s been said in the article up to this point, API testing can be summarised as following:

The tester (client) creates BODY, which is actually a JSON file, sends it as a REQUEST using a METHOD (in this case, POST method) to the server. Server checks the request and verifies whether it’s valid, then it returns a RESPONSE in JSON file format, along with a corresponding STATUS CODE.

This is the short summary of testing POST method via API. The process is the same with PUT method as well. With GET and DELETE methods, body is not used, but some query parameters in URL might be.

Part one – conclusion

I’ve introduced you with some basic terms and notions which are essential in API testing. Of course, this article has barely scratched the surface, as there are many other interesting and useful things which one can learn by looking into various available Internet resources which have HTTP, JSON and API testing explained in more details. Besides that, I’ve tried to show you some of the benefits of API testing which were evident in the process we’ve implemented in our workflow. Once again, I will emphasize that this article is oriented towards the automation testing beginners, not the experienced testing engineers.

In the second part of the article, I will show you how we’ve used our knowledge in practice and automated the whole API testing process using Postman. Hopefully, you’ll find some satisfying solutions in there.