What is API testing? How do you perform good API tests that have high ROI for testers? This can be a pretty daunting challenge if you’re new to APIs. So, to make it easier we will echo what Henry Ford once said, “Nothing is particularly hard if you divide it into small jobs”.
What is API? And What’s All The Fuss About?
API stands for Application Programming Interface. Just by following the literal meaning, we can conclude that it’s an interface, so essentially it acts as a medium between two or more computer applications. Recently, thanks to a constant user demand for the latest and best services, APIs have become the center of software development.
API testing is a software testing type that validates APIs to check the functionality, reliability and security of the interfaces. While UX/UI testing generally focuses on the look and feel of a website or app, API testing looks more at business logic: data responses and performance bottlenecks. Today, API testing is in the limelight thanks to increasing adoption of API strategies by businesses and consequently, the upturn in complexities in the IT sector.
Why Do We Need APIs?
And now onto the more important question: Why do we need APIs? A better analogy to understand this will be to ask ourselves why do we need electric-sockets in our homes?
When we plug something into a socket, we don’t have to understand the inner workings of the power system in order to use the electricity. Further, your plugged device can utilise electricity from other sources without having to rely on self generation of electricity. Let’s envisage that some of our power comes from the electric company and the rest from solar panels on the roof. Either way, the plug and electric flow is the same.
Similarly, APIs allow software engineers to focus on their core competency applications by taking care of the following:
- Interact with other applications for information or utilising resources by reading, creating
- Updating the information stored on other applications or servers
Types of APIs
APIs can be broadly classified into REST APIs, SOAP APIs and GraphQL APIs.
REST stands for Representational State Transfer. A RESTful Web service provides applications access to its Web resources in a textual representation and supports reading and modification of them with a stateless protocol and a predefined set of operations. In its essence, it’s an architectural style that has no official standard, it provides more flexibility as compared to SOAP. REST APIs use multiple standards like HTTP, XML, URL and JSON.
SOAP Stands for Simple Object Access Protocol. It’s a standard communication protocol system that permits processes using different operating systems, like Linux and Windows, to communicate via HTTP and its XML. SOAP API has an official standard because, unlike RESTful, it’s a protocol and offers structure, datatype control, and defined standards. This is sometimes preferred by businesses depending on their respective requirements.
GraphQL was created by a social media giant back in 2012 to support its mobile infrastructure application. It’s a data fetching specification that also functions as an API query language. In a nutshell, it combines the strengths of REST and SOAP APIs and offers a viable alternative.
API testing guide: how to test APIs effectively
There is a common pathway in terms of tools and strategy for testing the different APIs.
API testing strategy
First, a tester must understand the workflow of the application and analyze where, what and how APIs are in that flow. Understanding the purpose of APIs will guide us to what an API is expected to do. We can do the follow the below approach:
- Collaborate with the development team to understand APIs functions. In many cases, API documentation is kept by the development team which can act as a source of truth. Try and map out all different paths that must be tested.
- APIs are used to read, create and update information through our web browser. Consequently, when every action over the API Endpoint is an HTTP(S) request and hence the requested server will generate an HTTP Response code that confirms the success or failure of a request.
- Unfortunately, we can’t test APIs effectively over conventional web browsers. Postman is essentially a super-powered web browser that enables developers to tailor HTTP requests by editing sections, writing, and running tests that traditional web browsers can not.
- Now that we’ve tested common and expected responses over APIs, it’s essential to test:
- Multiple APIs endpoints producing duplicate results
- Endpoints over which a user should only be able to read data, should not allow create or update of information
- Information available at API endpoints should not be available via other endpoints that have been created by the user
Do’s and don'ts of API testing
There’s an openly available API site SWAPIwhich I found during my journey of API learning. Test it out using the request bar available on webpage on the site and while testing pay heed to the following key points:
- Check for Consistency: In swap.dev, the endpoint “people/1” (Luke Skywalker) has a relationship to planets/1. So we should verify that ”planets/1” has a relationship with “people/1”. Here we are checking if there's a relationship between two objects and that relationship should be defined consistently on both objects. Another example of this is “people/“, check the count and then try to see if consistency holds for “people/count+1”
- Make Sure Hidden APIs Are Not Searchable: One important consideration in API testing is to make sure that hidden resources aren't accidentally revealed. For example, an API endpoint allows us to search for information. While POSTing for search, we use the term “hidden”. If we get back zero results, it means that there's no results that have hidden in them, but this elucidates something. What if there was a result that was supposed to be hidden if we went directly to the URL (using an API tool like Postman) and it displayed hidden data in the search results? This is another example that we want to be careful of while testing APIs.
- Check for Intended Data Structure of API: This is done using the “/schema” command, it defines what an object needs to look like. For example, “people/ schema” will define what a people object schema will look like and its correct properties. These properties should include the name, height, films, URL, birth year, eye color, created, etc. The schema defines how the objects should look, and so while testing, one must verify that the people in the system conform to the API developers schema.
- Define All Paths (Un-Documented) to Access APIs (Especially Hidden/Restricted APIs): Sometimes, things are implemented assuming one path, and so as testers, we must ensure we're considering every path to the information.