How to test an API Manually

An API is a specification of the only permitted ways for one system to communicate with another. In this post, we will take a closer look at Web and REST APIs.

As you probably know, older systems used to have monolithic user interface integrations on the server-side. These were easier to implement but harder to extend and scale. The reason why these APIs came in is that they allowed you to write a single responsible service that could be reused by other systems. For example, you could write a server service that could connect to both mobile and web interfaces.

With the evolution of APIs, however, various standards and new approaches surfaced.
For example, SOAP APIs, which are a family of standards. The structure of these services is often predictable and their behavior is standardized. However, at the moment the REST (Representational State Transfer) is considered as a standard. It is faster and more flexible. Nevertheless, the REST is generally not predictable and standardized. Other approaches are available that are even faster and resource-efficient, but these are not as popular as REST: GraphQL and gRPC.

Why should we test an RESTful API? If you are a developer of this API, then you should check how your system works on the highest level. That will give you an understanding of how the multiple modules in your system work and that they communicate correctly. This is important for both development and support steps.

If you are a client for an API, which means you use an external API within your system, you should not only rely on documentation but also make sure that API works as expected (because the bugs on external services can also corrupt your system). Sometimes, there is only pure or outdated documentation that doesn’t describe all the components of the API. So you need to make some hypotheses and check them by API testing.

In this article, we are going to talk about REST APIs as the most common approach, but some of the tips can be applied to other architectures.

Testing Steps

Defining API structure and requirements

First of all, you need to define a general API structure and functionality. It’s possible that the API you are going to use provides reduced functionality that only partially suits your needs. How can you do this? Just explore documentation. It’s also possible to initially define some functionality on the basis of a REST standard. For example, each entity should have its own URL, for example, for user: /users. This URL is valid for collection operations, which means that you can add new users, get all the users in the system, etc. All these actions are represented by HTTP methods (GET, POST, PUT, etc.). There you can also get a certain user by unique ID as follows /users/<user_id>. So, with these principles in mind, you can make some hypotheses about the structure of API, even if it is not fully described.

The information you need from your documentation or other resources is:

1. All resources you need to use
2. All methods available for each resource
3. Input data that can be accepted by each resource
4. Output format
5. Response codes

Response codes are not really intuitive in most cases and that’s because there are no strict specifications. Most developers use the following HTTP response codes:

1. 100-199 – Information
2. 200-299 – Success codes
3. 300-399 – Redirect
4. 400-499 – User-side error (For example, not found exception or invalid data format)
5. 500-599 – Server-side error

Some of the codes are defined as follows:

• 200 – is generally OK code
• 404 – not found
• 403 – forbidden (authentication error)
• 500 – internal server error

Sometimes, it happens that a developer duplicates the response code, or returns only the response code in the response body, as follows:

{
  Code: 200,
  Status: Ok,
  ...
}

There is a problem in the formula because some developers prefer to return a 200 (OK) code when a resource was created, but others return 201 (Created) code. Why should you check these instances? Because this code will give you information about what is going on.

Also, don’t forget to pay attention to the API version you use.

Define test cases

As mentioned earlier, you should check all instances that are not clear to you or not described in the documentation. It’s also quite useful to create some test cases to check critical functionality. For example, if you are going to use a Face detection API, you can try it with different faces on different backgrounds with different clothes and nationalities, all of which are possible depending on your code.

You can also implement the testing of boundary cases. For example, if you are testing a calculator, try it with the lowest and highest values that are possible for the function. You can also check some cases that should produce an error, for example, negative values for a logarithm function.
These queries can be saved in some tools, like Postman or Paw, and reused in the future for quick debugging.

Performing Tests

The final step is just to perform all queries and check if everything works the way you need it to. Feel free to make some queries during the debugging process. It’s possible that the bug is on the other end.

What about tools that can help you with APIs testing? You can perform tests from code, using different libraries that allow you to send an HTTP request in an appropriate way. This way is inconvenient because it is hard to maintain and reuse it. A more appropriate method is to use something like Postman or a similar application. Postman saves your queries and gives you the ability to create collections (or convert them to OpenAPI) from them (that can represent your test cases).

You should check RapidAPI service, which solves almost all the problems we’ve listed in this post. You’ll be able to choose from a variety of APIs, ensuring you will use the most suitable one for your needs. You will also gain data pertaining to latency, success rate, resources, and description in one click. The other benefit of RapidAPI is that you can see an example of a request (resource, params, headers) and response (structure, response code, headers, etc). You can get a generated code that can be used in your system integration. There is also an interface to perform test queries with different parameters, so you don’t need to use additional software.

You can also use all the features of RapidAPI for your team internally in the private zone. Check RapidAPI for Teams to organize and reuse your own APIs. Monitor API usage and payments. You can add APIs in different ways.

You can also check metrics like errors, latency, and quota usage for each API call you made in your personal dashboard.

This enables you to maintain documentation in a convenient way. You will be able to quickly test all endpoints and ensure that everything is up-to-date. You can also attach any external API you want from the public zone. This will help you manage all your APIs in one place.

It’s also beneficial that you can start a discussion if you have a question or need a tutorial.

Conclusion

API testing is an important part of software development. It ensures that everything works as needed, tests some hypotheses, and explores. So it would be nice to perform some tests before you spend your resources. First, you need to explore all functionality that an API provides and then explore all resources, inputs, and outputs. After that, you can ensure that some critical parts work as expected using some test cases. You can use tools like Postman or choose RapidAPI, which will help with almost all steps of testing and maintaining the API.