API testing basics for beginners
API (Application Programming Interface) is the building block of software applications. More often than not, APIs are used to access data, facilitate interaction between multiple applications, enable communication between Microservices, etc.
While a good deal of software testers perceive working with API as a frightening experience, in reality, APIs are the simplest and most non-complicated way of dealing with applications. This article unveils the basic concepts of API testing with the aim to make one feel confident and comfortable interacting with APIs.
Let us take the first step towards understanding Web APIs with the bird’s view of the client-server diagram. This infamous client-server setup provides a wholesome picture of how web applications are designed.
Client/ client-side- includes all the devices that are used to interact with the application.
Internet is an enabler, it assists in transporting client requests towards Web-server along with relevant details filled by the user at the client-side.
Web-server/server-side is the holy place where all processing takes place. Once the processing is complete the data is pushed back to the client side.
Table Of Contents
APIs comes with 2 broad facets
1. Request– An encapsulation of action performed along with pertinent details to be sent to the server.
2. Response– An encapsulation of processed data along with supplement details sent back to client by the server.
Both request and response come with header attached. Take a look at any network call, you should be able to see headers quite evidently.
Request header carries all the supplemental details to be passed on to the server in order to process the request. In the example below, we see set of keys and values. The key names are case insensitive.
Sometimes Request also carries payload details, in the below example I am trying to join the Testsigma discord community. To make that happen, I am entering some details through UI and clicked on “Send” button. When the event is triggered, we can see in the backend call the payload is filled with the details passed to server.
When the request is processed by Webserver, response body is prepared along with additional header details. For example, while I choose to join the discord community, the API has responded with further details about filling captcha. During the API testing we are expected to do regressive testing on the response body to ensure details sent are as expected.
How are API called?
Each user interaction on UI is associated with an API that will be accessed through a URL. Let us say a user fills up a form and clicks on “Send” button, on trigger of this event respective API will be invoked. In the below picture we can see the Request URL is pointing to the endpoint ‘Signup’.
API Request Method
Every request is associated with the “Request Method”. This method specifies the desired action to be performed by the server. Below are the frequently used methods
1. GET: This method is used to retrieve the details, this performs a read-only operation.
2. POST: This method submits data by creating an entry into database. This method should be used wisely as it can change the state causing side effects if not handled properly.
3. PUT: This method is used to update any data, the data that needs to be replaced is sent as part of payload.
4. DELETE: This method just deletes the data.
5. HEAD: This is similar to get method, however there is no response body sent.
6. PATCH: This method specifies how to update the data, this can can cause side effects if not handled with care.
Few FAQs about request methods
1. How will I get to know which API follows what method?
Ideally software development teams maintain API documentations. Every API is preceded with the respective method in the documentation.
2. Can one API endpoint perform multiple actions?
Yes, sometimes same endpoint is designed to do multiple methods.
3. Can I use API without specifying method?
No, you have to suffice the API call with request method
4. Can all APIs be accessed through URL
Yes and NO, some APIs are open for public and may not need authentication. However most of the business and enterprise APIs are behind API gateway and one may have to authenticate before calling the API.
5. Can same endpoint have multiple method associated?
Yes, it is completely possible to define multiple actions/verbs for same endpoint. Hence it is important to know before hand what actions are supported by the API.
Every API request is associated with response. The response have 2 facets
1. Status code : Numeric representation of the web server response. There are pre-defined set of status code which can be reused. Or, teams can create their own status code as per convenience. However, appropriate status code range should be used.
2. Status Message : Each status code is associated with detailed response message.
Status code 200 → Success
Status code 401 → Unauthorized
Status code 404 → Not found
API usage is not as simple in real world, when companies are hosting large scale APIs protecting them from misuse is their primary concern. API gateway helps establishing authentication to verify the calls before transferring it to further execution. The capability of API gateway is not just restricted to authentication, it also provides multitude of services like
ii. Rate Limiting
v. Policies etc
Since APIs deal with protected resources, the request processing should be backed with authentication process to ensure the access is provided only to the intended user. There is a difference between authentication and authorisation.
Authentication is a process of verifying the identity of the user it solely answers who you are, whereas authorisation mostly deals with access management and comes into play only after the user is identified and verified successfully.
Most commonly used authentication are
1. Basic Authentication: This technique involve providing username and password for user verification. Authentication sounds little flimsy isn’t it?, but this is how it is going to work. When user enters their credentials the details are encoded in Base64 generating a Key which will be bundled in request header and sent to server for verification. Server Verifies the key with the stored
username and password. If the identity is verified the request is fulfilled else an error is sent back denying request sent.
2. API Key Authentication : API key is a long encrypted string which identifies the application without any principal. These are sent either as a part of request header or URL. When client recognises the API key server will process the request.
3. OAUTH Authentication : This technique is considered quite powerful and secure way of authenticating the users. oAuth technique can also be used for authorisation. Initially a user may have to login to the oAuth application using the credentials to generate a token. The generated token is attached as part of request header, which will be sent to authentication server in order to verify. If the token is recognised the API request will be processed
Generating Test cases for API testing
API testing is a black box testing technique, one don’t really delve into what is implemented within an API. Having said that, if you would like to particularly walk through the code to test the API that is fine too. The main task in testing APIs is to figure out the test cases just like any other tests out there.
For example consider the below REST API
Looking at the API method we understand that this is going to perform a read operation and fetch the details requested which is list of all users. The response returned will be in the JSON format. REST Apis generally use JSON structure to represent the response body.
Let us go ahead churning the test cases for this API
1. On Successful execution the API should return status code 200 (message : Success)
2. Specific user details can be fetched by passing user id in URL (https://gorest.co.in/public/v2/users/25)
3. The JSON response should match the below schema
4. Wrong URL should respond with 404 (Not found)
5. Multiple User ID in the URL should respond with 404 error
Go ahead churning out more use cases and try to cover all the positive and negative scenarios.
Happy Testing !
More related reads: