Skip to main content

An Application Programming Interface (API) allows two systems to communicate with one another. In essence, an API offers the contract and language that govern communication between two systems. 

API testing involves evaluating these interfaces to ensure they meet functionality, reliability, performance, and security standards, typically by sending various requests to the API and assessing the responses. API testing is a top priority for almost all developers, with over 90% of developers reporting testing or planning to test their APIs, according to Rapid’s 2022 worldwide API survey. 

API endpoints are specific paths or URLs that an API provides, allowing access to different functionalities of the software application. Each endpoint corresponds to a specific function, such as retrieving data, updating a record, or performing a calculation, and is designed to handle specific types of requests and responses within the API's overall structure.

Consistently testing API endpoints throughout the development process helps in the early detection of issues, saving time and resources in the long run.

SP, how can API testing be done efficiently throughout the API development life cycle? Let’s dive in!

What Are API Endpoints?

An API is a set of rules and protocols for building and interacting with software applications, allowing different software systems to communicate. The documentation and specifications for each API specify how data can be exchanged.

APIs can use HTTP requests to retrieve data from a web application or server, much like how a webpage is rendered.  

API endpoints: URLs that allow communication between different software applications. They define the entry points for accessing specific functionalities or data within an API.

services, URLs, just like the ones you use to visit a website. Within an API, an endpoint is a particular location that receives requests and responds to them. Through the transmission and reception of data and commands via the endpoint, it facilitates communication between various applications and systems.

It allows developers to quickly access and utilize data as well as features from other systems, saving them the trouble of building everything from scratch in new applications.

Example of An API Endpoint

Let’s see what an API endpoint looks like. I will use as an example the Cat API and their Postman documentation:

screenshot example of an API endpoint

In this case, the endpoints are “images,” “favorites,” “breeds,” etc. Each allows various actions, which are done through different HTTP request methods. For instance, the most commonly used methods are the ones that perform CRUD actions: POST for creation, GET for reading, PUT for update, and DELETE for deletion.

API documentation should provide details on the available endpoints, the request method allowed for the endpoint, and models of the request and the response. With this information, we should be able to start testing the endpoints. We’ll talk about this in one of the next sections.

Discover what’s new in the QA world.

Discover what’s new in the QA world.

  • By submitting this form, you agree to receive our newsletter and occasional emails related to The QA Lead. You can unsubscribe any time. For more details, please review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

Why Test API Endpoints?

Every API is built to carry out specific functions, and the functionality of the application depends on the API transactions to receive the response. The basic transaction may make many internal API calls; if one of these API calls fails, the system as a whole could fail and cease to function. Additionally, multiple applications can use the same API, so when an API malfunctions, it can harm a large number of applications. Testing API endpoints aids in preventing problems before the client finds them.

How to Test API Endpoints

API testing can be performed through manual testing, as well as automated testing. Both types of testing can be performed using API testing tools.

As opposed to UI tests, API tests are not dependent on a browser. However, an API testing tool that acts as a client can be used.

Based on the documentation, we can extract the endpoint where the HTTP request is to be sent, the HTTP method, the query parameters, the request body (if required), the possible HTTP response status codes, and the HTTP response body. Using this information, we can identify the API test cases that need to be executed.

Depending on the requirements, we can decide which tests need to be executed - from functional testing to non-functional, such as performance testing, load testing, and security testing.

The most basic API test consists of sending the request and validating the response. Depending on the request type and the endpoint itself, we may need some extra information to send the request. Here is a list of what we need to send a request:

  • Endpoint/URL: this is the address to which the request is sent
  • The request body: for request methods such as POST and PUT, a body is required, which contains the data to be sent to the server
  • Query parameters: additional search parameters can be used to limit the results returned in the response
  • Headers: these are meta-data that can be sent with the request. In the cat example from before, an API key can be used as a header, which allows retrieving more information than without a key:
guide screenshot

After the request has been sent successfully, the test should check the response. The things to look for in the response are:

  • The HTTP status code: each response has a status code. These can be grouped into 5 main classes: codes starting with 1 (100-199) represent an informational response, codes beginning with 2 (200-299) represent a successful message, codes between 300 and 399 are redirects, codes that begin with 4 (400-499) are client errors and codes in the 500s group are server errors.
  • The HTTP response body: the information that comes back from the server. The documentation should provide what type of information the response should contain, for example:
screenshot example response
  • Response headers: meta-data that is returned by the servers
  • Response time: if we are interested in the performance of the API as well.

For a quick example, I will use Postman to show what a GET request looks like using the Cat API. I will send a GET request for the images endpoint. To do that, it’s enough to use the endpoint address, the GET method, and send the request:

screenshot example

After sending the request, we can see the HTTP response code, the body, and the time it took to receive a response:

screenshot example

The response body content is what an API returns with the input provided, whereas the response status code indicates the request's current status.

There are differences in the data types and sizes of an API response. Plain text, an XML document, a JSON data structure, and other formats are all possible for the responses. A hundred-page JSON/XML file or a simple string of a few words, even empty, can be used for them. Therefore, selecting an appropriate verification technique for a particular API is crucial.

Creating Test Cases for API

The functional test cases can be extracted using black box testing techniques. The documentation specifies which types of data each parameter accepts, so partitions and boundaries can be created based on this data.

Then, we can create more complex scenarios by combining multiple requests into a test. For example, a test that creates a resource, updates it, reads it, and then deletes it will send 4 different requests.

Positive and negative tests are both necessary for API testing to verify that the API is functioning as required. Given that API testing is a subset of black-box testing, input and output data are the driving forces behind both kinds of testing. A few ideas for creating test scenarios are as follows:

Positive scenarios:

  • Check that the API accepts input and produces the desired result per the requirement.
  • Check to see if the response status code—whether it returns an error code or a 2xx—is returned in the manner indicated by the requirement.
  • Indicate the minimum and maximum number of fields that must be entered.

Negative scenarios:

  • Make sure that in cases where the expected output is absent, the API provides a suitable response.
  • Run a test for input validation.
  • Examine the actions of the API at various authorization levels.

Non-functional API tests 

Apart from functional testing, we can perform various non-functional tests for APIs. Here are some of the most important ones:

Performance testing

Performance testing refers to measuring the software's performance under various workloads, scenarios, and conditions. It can assist you in finding resource bottlenecks, guaranteeing stability and scalability, and ensuring scalability. Subtypes of performance testing include load testing, stress testing, endurance testing, and spike testing. The most popular performance testing, known as load testing, replicates average or high user traffic on your software. It can assist you in assessing your software's throughput, response time, and resource usage. Apache JMeter, an open-source Java tool that can generate and send different requests to your API and measure the results, is one of the best tools for load testing your API.

Security testing

The process of confirming that your software is shielded from malicious attacks, unauthorized access, and data breaches is known as security testing. It can assist you in guaranteeing the privacy, accuracy, and accessibility of your program's data. Various levels of security testing can be carried out, including database, application, and network levels. Code reviews, penetration tests, vulnerability scans, and ethical hacking are a few popular methods for security testing. Postman is a well-liked cross-platform utility that can send and receive requests to your API and test security features like authentication, authorization, encryption, and error handling. It's one of the best tools for security testing your API.

Reliability testing

Reliability testing is the process of determining how dependable and consistent your software is over time and in various situations. It can assist you in guaranteeing your software's recoverability, fault tolerance, and availability. You can do reliability testing by intentionally introducing bugs, errors, or failures into your software and seeing how it reacts and bounces back. Mean time between failures (MTBF), mean time to failure (MTTF), mean time to repair (MTTR), and failure rate are a few of the frequently used metrics for reliability testing. Chaos Monkey, a tool that randomly terminates instances in your cloud environment and tests how your software handles the disruption, is one of the best tools for reliability testing your API.

Final Thoughts

API testing is an increasingly important skill for QA professionals. It is essential to thoroughly test API endpoints to ensure they function as intended and meet the required standards. Testing API endpoints helps identify and resolve potential issues or bugs and validates the application's overall functionality.

To effectively test API endpoints, it is essential to follow best practices such as designing comprehensive test cases, considering various inputs and outputs, and utilizing automation tools for efficient and reliable testing. Additionally, leveraging test environments that closely simulate real-world scenarios can further enhance the accuracy of API endpoint testing.

Comprehensive and effective API endpoint testing is essential for ensuring the reliability, performance, and functionality of modern applications. By understanding what API endpoints are and how to test them, developers can ensure the successful integration of their applications with other systems while delivering an exceptional user experience.

Please subscribe to the QA Lead newsletter to receive updates on new testing content.

Andreea Draniceanu
By Andreea Draniceanu

Hi there! My name is Andreea, I’m a software test engineer based in Romania. I’ve been in the software industry for over 10 years. Currently my main focus is UI test automation with C#, but I love exploring all QA-related areas 😊