API stands for Application Programming Interface; here is the Oxford definition: "a set of functions and procedures allowing the creation of applications that access the features or data of an operating system, application, or other services."
A more simple explanation: let’s imagine we are sitting at a restaurant, where we interact with a waiter. He will take our order, answer our questions, and deliver the food back to our table when it is ready. The waiter is in charge of all the complicated stuff that happens behind the scenes; we don’t have to worry about the stoves, dishes, drinks, and so on. In a way, the waiter can be seen as the restaurant’s API.
APIs allow different programs to work together in various ways. They are used to access data so that multiple apps or services can work together.
There are different types of API. The following are classified based on release policy:
Internal/Private - these are only available for internal systems
Partner - restricted, only available for known business partners
Public - mostly designed for end customers/third parties
There are different types of protocols, architectures, and styles for APIs. Here is a brief list:
REST (Representational State Transfer) - a trendy API architecture based on URIs (Uniform Resource Identifier) HTTP protocol. It uses different data formats including plain text, HTML, XML, and JSON.
RPC (Remote Procedure Call) - the oldest type of API; there are two kinds of RPC: XML and JSON.
SOAP (Simple Object Access Protocol) - this protocol uses XML as a format to transfer data. It also uses Web Services Definition Language (WSDL).
GraphQL (Graph Query Language) - a query language for API that allows clients to declaratively describe their data requirements with a JSON-like format.
Since API testing allows access to the application without the need to use the interface, it will provide a faster, more efficient evaluation of a build in the test cycle. It will expose any errors or if something is broken in the business layer, it will help to uncover small issues before they become larger.
If you are interested in using an API testing tool, it’s necessary to review its pros and cons beforehand to find out if it fits your needs. The following is a list of recommended tools:
Katalon (SOAP and REST)
SoapUI (SOAP and REST)
Postman (REST)
JMeter (SOAP and REST)
REST-assured (Java - REST)
RestSharp (C# - REST)
Karate DSL (Java - SOAP, and REST)
API testing covers the following:
Unit Testing - tests the functionality of a single endpoint with a single request and looks for a response or a set of responses
Functional Testing - checks if the API works and does exactly what it's supposed to do
Load Testing - verifies if the API can handle a normal and/or a large number of requests
Security Testing - checks the type of authentication required, be it permissions, access, or controls
Reliability Testing - confirms if the API provides consistent connection and provides consistent results
Negative Testing - verifies how the output data behaves when invalid input is provided.
API Documentation Testing - checks if the documentation provides an easy guide for the user
API Testing verifies the following items:
Authorization
Input parameters
Payload structure
Response structure
Expected Results
HTTP Status code
Error Handling
Response time
Others
API testing can help to find different type of bugs; below is a brief list:
Unused flags
Missing or duplicate functionality
Failure to handle errors
Security issues
Inadequate error responses
An incorrect response data structure
High response time
Some tips before you begin:
Get familiar with each API you will be testing
Group test cases by category
Prioritize your API test cases
Analyze the input combination that will be used for each test case
Always try to order your test cases in CRUD order: Create, Read, Update, and Delete.
{{cta('7ee55d50-07e4-4a46-8520-d9c33cb774b7')}}