Why is testing on APIS necessary?

In order to talk about API testing, the first thing to know is what an API is, well, an API or Application Programming Interface is a set of definitions and protocols that are used to develop and integrate application software, allowing communication between different software applications through a set of rules.

APIs emerged in the early days of computing, long before the personal computer. At that time, an API was typically used as a library for operating systems. They were almost always enabled locally on the systems on which they operated, although sometimes they passed messages between host computers. After almost 30 years, APIs expanded beyond local environments. By the early 2000s, they were already an important technology for remote data integration.

What is an API for?

An API makes our work easier when developing software and, so we can save time and money. For example, if we create a website where we can consult the current weather, instead of having to do all the development to obtain accurate weather information, we can make use of the meteomatics APIs, which, with a simple query to its interfaces, will return the information we require regarding the current weather. In this way, it often avoids having to spend time and money on developing something that already exists and is available to other developers.

APIS testing

API testing is often overlooked when it comes to automation, but in fact its cost/benefit ratio is much higher than front-end automation.

With the advantages in the use of APIs, needs arise such as testing non-functional requirements such as response times or the maximum capacity of requests per second supported, or functional requirements such as validating that the content of the response is as expected.

Addressing these situations, there are different types of testing that can be applied to APIs such as:

• Automated testing
• Performance testing

Automated testing is mainly responsible for checking or validating the response of the request, whether it is as expected and whether the types of data to be received by the Interface are correct.

Performance testing, on the other hand, is mainly concerned with obtaining system metrics and testing the speed of response based on the simulation of multiple concurrent requests and, in this way, to see what level of load the Interface can support.

Testing an API, the first thing to do is to know the different status codes of the request made:

• 1xx Status Code => Information
• 2xx Status Code => Successful request
• 3xx Status Code => Redirection
• 4xx Status Code => Error on Client side
• 5xx Status Code => Error on Server side

Within each category there are different information messages depending on the value of xx, this information can be found in restfulapi. To be able to test on API there are different tools that allow us to perform this function, one of the most used is Postman.

Although for personal use we can use the free version, Postman also has different paid licences with better features such as being able to recover deleted collections or have collaborations between teams of 4 or more members to work on the same collections.

This programme allows you to make as many requests as you need, and you can also group the requests in different collections (folders) according to the API you want to test.

Postman can also perform the automatic execution of a collection, thus launching the different requests that have been stored in the collection.

In addition, different tests can be generated within each request using the internal pm library to check, for example, expected data type, status code value, value of a specific field in the response, header types, etc.

There is a command line runner that allows you to run the collections where the saved API requests are located

To generate scripts, you can consult the official Postman information, where everything about how to work is documented in the Test section within each request or collection. There are other tools that allow us to test on APIs such as SoapUI, but the most commonly used is Postman for advantages such as the following:

• Supports collaboration between team members.
• It has a much more intuitive and attractive interface, which makes it easier to use.
• It has an API Network, which is a repository of APIs that allows direct access to them, as well as the possibility of documenting and studying their use. It is also possible to publish APIs in this service privately, only accessible by a specific organisation.
• Postman is more widely used, so there is more documentation.
• Licensing costs are cheaper than other tools.

In addition, there is a command line runner that allows you to run the collections where the saved API requests are located. This runner is called Newman. This add-on is widely used, especially when it comes to Continuous Integration (CI). It allows, through tools such as Jenkins, to run Postman collections in a simple way, and in addition, in the official Postman documentation there is a section on how to integrate Newman with CI tools.

Is APIS testing really necessary?

Over time, the use of APIs has become increasingly common in the development of products and services. Many applications are based on the use of these interfaces to collect information from different sources and thus have a centralised system in which to consult information; for example, when we want to consult different rates for hotels, insurance, products, etc.

This type of pages that offer comparisons between different companies with the same product ultimately make use of these APIs to collect information quickly and efficiently. Therefore, it is essential that these APIs work correctly: without errors and with an adequate response time.

API-First architecture

The API of a web application is often seen as a secondary element, which is not necessarily a mistake.

However, if what you are thinking about is a service as a complex system, in which there are multiple points of contact with users, such as web, mobile, customer service offices, etc. In this case, it is advisable to think about and design the architecture of your platform focusing on the APIs that enable its operation, and that is where the API First architecture comes in.

API First is an architecture that treats the API user as the primary user of the application. This means that the API is not seen as an alternative in the MVC paradigm, but has the highest priority.

In API-First the architecture imposes a complete, responsive and well-documented API. Making use of this architecture makes it easier to see the need and importance of testing the APIs since, in the end, the correct functioning of the core of the application is guaranteed.

In another article we will discuss in detail the correct approach to testing applications with API-First architecture.