It is expected that you are already familiar with APIs, what API testing is, etc. Without going into too much detail on these topics, let’s just summarize it.
API Testing is in which you apply testing strategies, concepts and techniques in order to verify that the API under testing fully complies with its expected functionalities. It also makes sure that your API follows the required and previously set specifications. Not only that, it may also involve verifying the security and performance behavior for your API.
Request, response, status code; are these words familiar?
These are the first things that come to your mind when you hear the term “API Testing” or when your team asks you to test some APIs. But, is it just these or are there more components of API testing? In this article, we will dive into the different components of API testing and give advice on how to approach each.
What to test in APIs?
When it comes to API testing, a lot of aspects need to be looked at, we will discuss the most important ones in the coming points.
Imagine you have been asked to test an API, within that API there’s a group of endpoints that provide some functionalities. Let’s say we will be working on an endpoint which deals with user’s information (ex: https://x-env.server.com/api/v1/user).
Supported Methods
The first thing you should be thinking of is which methods are supported by that endpoint. Does it only support one HTTP method or more than one. For example, does it only support GET, or maybe it also supports POST and DELETE in addition to GET.
You will need to test two things, one is to test the supported methods and verify it’s actually working as expected, and second is to also verify that the un-supported methods are not throwing errors, not showing 5XX errors, and are handled correctly in a way that mentions that this method is not supported by this endpoint.
Some developers tend not to handle that and let the web server deal with it while showing a 404 Not Found response. There’s no wrong here but it’s best practice to handle it and let your consumer know it’s not supported, maybe by returning 405 Method Not Allowed.
HTTP vs HTTPS
Verifying the connection security of your API/Endpoints and whether it uses a secure protocol like HTTPS, or not like HTTP, or both, depends on the security requirements and your API/Endpoint implementation.
Without doubt, using secure protocol is most recommended, but apart from this you will have to test all the cases. If it supports HTTPS, you will have to use it while testing and checking that everything is ok and no certificate error appears. This is in addition to verifying that HTTP is not allowed and showing to the user that you must use a secure protocol.
Path Parameters vs Query Parameters
For those who don’t know what the difference between path parameters and query parameters is, let’s make a quick note.
Path parameters define the location of the resource you are requesting (ex: https://x-env.server.com/api/v1/user/{userId}/posts) where {userId} is the path parameter (without the curly bracket).
Query parameters define a filter criteria, sorting criteria, or pagination and so on, (ex: https://x-env.server.com/api/v1/user/{userId}/posts?sort=asc&showLikes=false) where sort is defined as a parameter to be ascending and showLikes is also a parameter defines whether to show posts likes or no.
For the path parameter, you will need to test a bunch of positive and negative scenarios. What if you provided a non-existing path parameter? you would verify the API behavior in that case, and make sure it’s handled correctly.
What about not providing a path parameter at all? It’s also a good scenario to check. Then finally, you would test a valid path parameter.
For the query parameters, it depends on the type of parameter. As a general rule, you would be checking valid and non-valid parameter values. Then, depending on parameter type there will be other scenarios to verify.
As an example let’s look at the pagination parameter. For this parameter, in addition to the general rule, you would need to verify what would happen if you tried to go beyond the limits? Like a page number that does not exist, a limit value that is more than what’s configured on a single page, and so on.
You would also need to check if you provide the parameter key but with “null”, or if you didn’t provide a value but you provided the key, what if you provide a non-existing key, and so on.
Headers
Headers as you know, are a key value pair that are sent within a request or received within a response. There are some generic headers that you will always see mostly by default, for example the Content-Type, Accept and so on.
For these generic ones, you might need to provide a content-type that is not allowed or configured by the API like application/xml if your api only supports JSON. The same rule applies for the rest of the headers.
As for the custom headers that you manually provide, apart from the valid scenarios, you would have to check the behavior on some negative scenarios. A couple of these scenarios could be:
- Providing a header name (key), but without a value.
- Not providing the header at all.
- Providing a header key with invalid value.
- Providing a header, that is not known by the backend API.
- Providing invalid value for a header with a long one or maybe containing code.
If you keep thinking on the matter, you will find lots of similar scenarios to check.
Request Body
One of the most important parts of a request is its body. The request body is actually based on the API specification for the current endpoint. Check your API specifications and know what is required, what’s not, data type, and data structure needed to be sent within the request.
When it comes to the request body, a lot of scenarios would come to your mind. A list of possible testing scenarios for a request body could be:
- Not providing a body at all, while it’s mandatory.
- If you are sending a JSON body for example, try sending an empty object “{}”.
- Missing fields.
- Providing valid field names but wrong or empty values.
- Providing “null” to some fields.
- Providing a string to a field that needs Integer and vice versa and so on for data types.
- Providing a non-array object for an array field.
- Providing new fields that your API does not know about.
- Providing long values for some fields.
- Not providing mandatory fields while providing optional ones.
- Providing a value that may contain JS code.
- Providing values that broke field validations.
The list won’t end when we talk about request bodies, think of a case that broke validations, maybe not correctly handled, out of the box you find a lot.
Response Body & Response Headers
Response is the most vital part of API testing, as it’s the part that’s most tested and verified, it can be divided into three parts. These parts are the response body, response headers, and response status code. The status code part will be covered in the next point.
Coming back to the response body, there’s a lot to verify in your response body to make sure your API is working as expected. The first thing you need to look at is that your API is actually behaving as it’s expected. If you request data, you should see something matching your expectation, when you add data, you should get a response verifying the data was actually submitted, and so on.
Then, digging deeper into your response there is much to check. You will need to check that all the fields on the API response body match your API specifications, no missing fields, no extra fields.
Also, you should not see fields with “null” or empty values when it’s expected to have specific values. Response format should be also checked, if you expect JSON or XML.
Data types of your fields are so important, if you expect to have integer value on a field it can’t be a string. If you expect to see an array, you must see an array. And so on for the rest of known or custom data types.
If your response is sorted somehow, you need to verify this sort.
Make sure also you find the correct headers in the response headers, based on your API specification, check if the API is sending custom headers and what their values should be. Verify also that headers exist in the first place, it might be missing.
Status Codes
Status codes are response codes that let you know what your request status was. Always check your status code to see whether it’s showing the expected ones or not.
For example, for every successful scenario you would see the 2xx status codes, for a validation error or some mistakes you might make while sending your request you should see 4xx status codes. As for any unhandled scenario, case, or behavior, the server might respond with 5xx type of status codes.
As mentioned before, if you are using a HTTP method that is not allowed, you would get a 405 status code, and so on. The mentioned status codes are recommended and mostly known for these types of actions, but your API developer might choose to send a different one.
Performance
Performance is a big topic, and on an API level there’s a very long list to check. But in our case, we will talk about one tiny aspect, which is API response time.
Response times may vary between one API to another, one endpoint to another, and so on. It’s based on a lot of things like requirements, type of request, data size, network speed, …etc.
In general, requests should not take seconds to respond, most times for general purpose API’s are under one second, and they could be less than 300ms in some cases or less. Based on your requirements you would know what the allowed time for the API to respond is..
What you need to verify here is whatever requests you make to the API, it’s not exceeding the response time allowed. If it’s exceeded there might be a network issue on your side, so try a couple of times and maybe try from different places.
Authentication
When testing your API’s, in many cases you will find yourself in need of a token (access token) to authenticate to that API and have the access to call it. That process is called Authentication, where the API is secured to only allow people or systems with trusted generated tokens to call the API.
There are many forms of authentication like basic, bearer and Oauth2 and so on. It’s so important to test your API security and verify it only accepts what it’s only supposed to accept.
As a summary, here’s some scenarios you must check to verify that everything is ok:
- Verify sending an empty or invalid token (it should not accept and respond with 401 UNAUTHORIZED).
- Verify sending a valid token, but not generated from a trusted place or generated from a place other than what your API expects (it should not accept and respond with 401).
- Verify sending a valid token, generated from a trusted place (valid case).
- Verify sending a valid token, but it has already expired (401 UNAUTHORIZED).
Authorization
You may find authorization comes a lot with authentication as these two are vital information security processes that are used to protect systems and information.
Authorization means that we know who you are, you come from a trusted source, and we also know that you used a valid token to call our API. But what we are trying to do here is to who you are, do you have the right to be here, do you have permission to request this data, or do you have access to update that resource and so on.
So, you provided a valid token to your API, but you need to verify whether your resources are only accessed by authorized people or not. If we have a delete action on an endpoint like /user?id=727272, and only admins can do that action.
You should already know what to test here, right? Yes, you got it right. It’s necessary to check the scenarios below while testing authorization:
- Using a valid token, but has no role at all (not accepted and gets 403 Forbidden).
- Using a valid token, but has no admin role ( 403 Forbidden also).
- Using a valid token, and has an admin role (accepted).
- Using a valid token, valid admin role, but the token already expired (401 UNAUTHORIZED).
Please also pay attention when it comes to security, as it may hurt your information security if something was missing.
Rate Limiting
Security can come in many forms when it comes to API testing. One of the things that might apply to your API under testing is rate limiting.
Rate limiting can be defined as a rate limitation that is put on some API’s/Endpoints to limit the traffic sent to that API. The purpose of this is to limit how many requests could be sent over to this endpoint to overcome many problems, one of them is brute force.
So back to our testing, if you have a login endpoint, and based on your requirement you may need to verify the rate limiting, which can be 5 times in 10 seconds from the same IP.
What you will need to check here is that you can’t make a request to that endpoint more than 5 times during a 10 second period from the same IP. You will need to test other cases also like requesting it 5+ times but in more than 10 seconds. Maybe checking from multiple IPs at the same time if you can and so on.
The rate limiting topic is a big one, and can come in many shapes with a lot of negative and positive scenarios to test. This was just a hint and we definitely suggest taking a deeper look into this topic separately.
Conclusion
As you may have seen, there’s a lot of things to be aware of or take into consideration when it comes to API Testing and verification. Of course, the mentioned topics are not the only things to verify. There’s still a lot to consider and you will gain more knowledge while you practice API testing continuously.
Depending upon the type of API/Endpoint, you may come across additional elements to consider. Things may also depend on the business logic of the system under test. Please keep in mind that an API might be simple to test, and in those cases, you should not overthink it.
The list has not come to an end, it will stay open and continue to grow. So, we will keep this document live and revisit this topic soon again. Stay tuned.
Thanks for reading, and happy testing!
Author:
Kamar Zaghloul is a Software Engineer with strong experience in object-oriented programming languages (Java and dot NET), Test Automation, APIs (Testing & Development), and Databases. In addition to building Automation Frameworks and Tools, he is also experienced in building web and mobile applications using Java, C#, ASP.NET, and JS. Kamar is a constant learner and loves to stay on top of trending technologies.
