Best Practices for REST API Testing

What to Expect on This Page

The Challenges of REST API Testing

Delivering high quality REST APIs is a challenging task, as they are highly complex: Some code is difficult to reach, endpoints can consume countless parameter combinations, and constantly communicate with a vast number of other systems. Looking for any type of weakness putting stability at risk or even opening doors for attackers in REST APIs manually is like looking for a needle in a haystack. To deal with the complexity of REST APIs, dev teams test APIs with automated methods. Below, you can find an overview of the top 6 challenges of REST API testing.

1. High Number of REST API Parameter Combinations

As presented below, REST APIs consist of various different parameters such as request method, request URI and query parameter - just to name a few. These parameters can take up countless combinations that have to be tested, as specific parameter combinations can lead to erroneous program states. Documentation like e.g. “OpenAPI” may not even reveal the existence of some parameters.

2. Validating REST API Parameters

Validating REST API parameters is highly challenging. If they are not validated properly, issues such as wrong string/data types and parameter data outside the predefined value range can come up.

3. Maintaining the Data Formatting Schema

The data formatting schema specifies how REST APIs handle responses and requests. The challenge in maintaining data formatting is that whenever new parameters are added, they have to be included in the schema.

4. Testing REST API Call Sequences

Testers need to ensure that REST API calls are called in the correct order to prevent errors. In REST APIs this is especially important since they are generally multithreaded.

5. REST API Testing Set-Up

Setting up automated testing cycles is the part of REST API testing that requires the most manual effort. Especially for large projects enterprise testing platforms will help you speed up the initial set-up dramatically.

6. Error Reporting for REST APIs

Testing the API just from outside without knowledge of the code, and error reporting for REST APIs is tricky, as we frequently see a state involved, and reproducing might be tricky. The best way to monitor and report REST API tests is with coverage-guided testing approaches, as they know each line of code, track where exactly issues happen, and even collect coverage information in one go.

How to Automate Testing for REST APIs

Due to the complex structure of REST APIs, automated testing is one of the most effective ways to ensure smooth, reliable and secure operation. But not all automated testing approaches are equally effective. The fastest way to implement software test automation would be any testing of the final API running on a server with API testing tools, such as Burp or OWASP ZAP, potentially enhanced with some additional system tests.

Although these approaches are somewhat automated, they leave plenty of room for improvement, as they still require testers to have prior knowledge about the system under test in order to be effective. These tests are great to test APIs from an attacker's perspective. But they do not make use of the biggest advantage developers of an API have: Knowledge of the source code. They generate test inputs randomly, from static corpora, from OpenAPI imports, or based on heuristics. However, such inputs often fail to reach complex issues and edge cases, since they do not take code coverage into account. For example, such a testing tool would take the API request from above and try out countless different parameter settings in hopes of identifying a request that breaks something.

Automated testing from inside the code is far more effective at finding buggy REST API requests: Since they use information about the source code, these approaches can automatically exclude irrelevant parameter settings from the corpus. Through information about code coverage, they can find crashing REST API requests much faster and much more accurately. This automation also enables better reporting by providing code-coverage visibility. The advantages of this approach are especially useful to test vast microservice environments that are connected through APIs, and projects that are expanding in size.

Testing Before Deploying vs After Deploying

While there are several different ways to test a REST API, one of the most helpful distinctions is to consider testing before and after deploying a service. In this case, this could mean deploying a REST API to a development environment or developer’s workstation, deploying to an internal-only test or staging environment for testing by multiple individuals and teams, or deploying to production to some or all end users. Testing before deployment usually means unit testing, and testing either the underlying business logic of a REST API as well as the API service itself. Both testing before and after deployment are critical to ensure a high quality API.

Testing before deployment is effective for testing business logic and rules of the service. Functional unit testing is an excellent approach here, since the developer has full control over the source code and can create unit test cases based on the business requirements. Finding any type of bug based on unit testing and integrated end point testing before deployment greatly reduces the risk of such defects affecting end users or even other developer teams that may use the API service. In addition, testing pre-deployment has the benefit of significantly faster execution time, since network connections are mocked out completely. Network overhead is typically the bottle neck when testing APIs. 

Testing the API endpoints before deployment also has the benefit of much faster turn around times and less management overhead. Fuzz testing is one approach invented to find major software flaws in both the business logic layer and REST API service layer. Using fuzzing for automatically cover all edge cases a developer did not think about and is an excellent way for application developers to “shift left”, take over full responsibility for the API while using familiar test frameworks, tools, and processes.

Fuzz Testing for REST APIs

The most efficient way to implement automated API testing is with feedback-based fuzzing. Feedback-based fuzz testing is a form of data-driven testing, during which code instrumentation is used to measure the test progress within individual microservices and APIs. Through this instrumentation, the fuzzer collects information about test inputs, which it then uses to create further inputs that traverse even more code paths. Modern fuzzing solutions can be customized to scan for specific bug classes and to remove blockers. Since this technology can be integrated into any build system, it enables developers to continuously test APIs for all types of bugs caused by unexpected inputs. 

As mentioned above, fuzzing a service pre-deployment and locally on a developer machine like any unit test, is a great approach for testing of a REST API because of the reduced latency of local testing. This allows feedback-based fuzz testing to execute faster and find all code issues later qA stages might have found efficiently, customers may have found and even worse: hackers might have exploited. Developers can take advantage of fuzzing during development of an API to find all types of defects even before deploying a service to an internal test environment.

FAQs