What Is REST and Why Should You Test REST APIs?
Representational State Transfer (REST) is a software architectural style that defines certain rules (constraints). For example, a REST constraint states that a web application must be able to deliver data whenever a command is given.
API testing helps ensure that the API functionality of an application works as expected without any errors or deviations. It usually involves testing activities on a collection of APIs.
Here are key reasons to test APIs:
- Early detection of issues—API tests are conducted before an application is coupled with any user interface (UI) components. This enables developers to detect errors and misconfigurations early on and easily apply the fix during the API testing phase. It can also help reduce costs, because applying fixes later during development may be more difficult and time consuming, accumulating more costs.
- Consistent business logic—usually, an application uses the same set of APIs across multiple platforms, including desktops and mobile devices. Testing API collections can help ensure that the same business logic offers the same functionality across all platforms.
- Security testing—API security is a critical concern for production APIs. By testing your API, you can discover business logic issues and security vulnerabilities that can expose your API to attacks.
In this article:
- REST API Testing Basics
- What Aspects of the REST API Should You Test?
- Challenges of API Testing
- 8 REST API Testing Tips You Must Know
- Use Smoke Tests for Initial Testing
- Keep Track of API Responses
- Recreate Production Conditions for Your Tests
- Conduct Negative Testing
- Recreate Production Conditions for API Tests
- Eliminate Dependencies Where Possible
- Enforce SLAs
- Don’t Neglect Security Tests
REST API Testing Basics
When testing a REST API, there are two things to focus on – HTTP commands and status codes.
REST APIs use five HTTP commands:
- GET—retrieves the data from a given URL
- PUT—updates the previous resource or creates new data at a given URL
- PATCH—handles partial updates
- POST—enables the development of a new entity (you can also use this command to send data to the server)
- DELETE—deletes any current representations at a given URL
You will use these commands in your tests to explore how the API behaves in different situations.
REST APIs return standard HTTP status codes:
- 1xx (100-199)—an informational response
- 2xx (200-299)—successful response confirmed
- 3xx (300-399)—further action required to meet the request
- 4xx (400-499)—the syntax is flawed and the server cannot complete the request
- 5xx (500-599)—the server has completely failed to complete the request
You can use status codes to understand the outcomes of your requests. If the application is functioning properly, the results of the REST API automation test will fall into the 2xx range. A response in the 3xx range usually does not affect user experience and is not considered an error.
Status codes in the 4xx and 5xx ranges however, indicate that something is wrong and the users will receive error messages when using the API. The 4xx range usually indicates an error at the client or browser level, while the 5xx range indicates an error at the server level.
What Aspects of the REST API Should You Test?
Here are several aspects of the REST API you should test:
API Test Actions
A rest API test typically consists of test actions, which the test needs to implement per each API test flow. Here are several actions that should be included in a test, which should be applied for every API request:
- Verify that the right HTTP status code is returned—for instance, the creation of a resource should receive a response of 201 CREATED and an unpermitted request should receive a response of 403 FORBIDDEN.
- Verify the response payload—check valid JSON body and field types, names and values. This check should include error responses.
- Verify the response headers—HTTP server headers impact both security and performance.
- Verify that the application state is correct—this action is optional and can be applied primarily to manual testing. You can also use it when a user interface (UI) or another interface is easy to inspect.
- Verify performance sanity—for example, a test may fail if an operation was successfully completed but took too long.
Test Scenario Categories
Here are key general test scenario groups:
- Basic positive tests—also known as happy paths, these tests check the API’s acceptance criteria and basic functionality.
- Extended positive testing—checks additional optional parameters that fall outside the scope of a basic positive test.
- Negative testing—tests that use both valid and invalid user inputs to assess how well the application handles problematic scenarios.
- Destructive testing—a more advanced form of negative testing. It involves intentionally attempting to break an API in order to check its robustness.
- Security, authorization and permission tests—check security and access controls to see if the API includes any vulnerabilities.
Test Flows
Here are the three main types of test flows:
- Testing a request in isolation—involves executing an API request and assessing the response. There are basic tests that serve as the building blocks of the flow. If these tests fail, there is no need to run additional tests.
- A combined web UI and API test—applies to manual tests that check data integrity and consistency between a UI and the API.
- A multi-step workflow with multiple requests—involves testing a series of requests that represent common actions by users.
Related content: Get more background about testing APIs in our detailed guide to API security testing
Challenges of API Testing
There are several challenges of API testing, which you should be aware of as you build your testing strategy:
- Managing test data—traditional UI testing focuses on the functionality of an entire application. This means the test provides the input and validates the output against predicted outcomes. In API testing, the scenarios or use cases being tested involve predictions of faster and more effective performance.
- API versioning impact—versioning increasingly complicates API Testing. The majority of systems have a certain degree of depreciation, and this means an API needs to handle old to new versions.
- Understanding the logic of business applications—APIs typically come with rules and guidelines, including copyright and storage policies, rate limits, as well as display policies. The overall business architecture logic defines the APIs developed, integrated and used. API QA testers that do not understand this business application logic may experience uncertainty about test objectives.
- Keeping the API testing schema updated—the schema consists of data formatting and storage, including API requests and responses. Enhancements to the program, which can generate additional parameters for API calls, must take into account the configuration of the schema.
- Managing the sequence API calls—to work correctly, API calls usually need to appear in a specified sequence. If, for example, the API receives a request to return the profile information of a user before a user profile is even created, it will return an error. When it involves software applications with multiple threads, this process can become highly complex.
- Validating parameters—API tests involve validating parameters that are sent via API requests. This can be difficult to do for a large set of parameters and validation options. It requires making sure that all parameters use the right type of data (i.e. numerical data), and that it matches the specified value range, length restrictions, and other criteria for validation.
8 REST API Testing Tips You Must Know
Here are some best practices to help you implement an effective API testing strategy.
Learn more about these and other best practices in our guide to API security best practices
Use Smoke Tests for Initial Testing
You should first test new APIs using smoke tests. A smoke test is a fast, easy way of validating the code of an API to ensure that it functions as intended on a basic level. This may involve checking if the API responds to calls, responds correctly, or interacts properly with other components.
Smoke tests are quicker than full tests, so they can help you save time by detecting and remediating flaws immediately. You can reinforce these with sanity tests, which evaluate whether the results of a smoke test match the intended purpose of the API. Sanity testing ensures that the API interprets and displays data correctly. For example, an exchange rate API should display results that match the current exchange rate.
Keep Track of API Responses
Developers and testers commonly delete the API responses from tests. However, all responses should be retained for posterity, so they can be used as benchmarks for the functioning of each iteration. If a future change to the API causes an error, the record of API responses will allow developers or testers to investigate the error and compare it to previous iterations. This makes it easier to identify the exact cause of the error.
Recreate Production Conditions for Your Tests
Try to simulate the real conditions that you expect will affect the API in production or upon public release. This ensures your tests reflect the API’s functionality and performance in an accurate context.
Conduct Negative Testing
Positive testing is a standard API testing practice, which involves providing valid data inputs to test whether the API completes the request. However, you should also test the API’s ability to handle negative responses. This lets you see if the API responds well to invalid data, for instance by returning an error message, rather than stopping or crashing.
Recreate Production Conditions for API Tests
Tests should always be designed to reflect real-world conditions as closely as possible. This ensures that the API will perform as intended in the actual production environment. Testers can more accurately assess and resolve performance issues when tests simulate production conditions.
Eliminate Dependencies Where Possible
API testing often involves dependencies, such as third-party services, external servers and legacy systems. You should reduce the number of dependencies your API testing process relies on, in order to make testing faster and more efficient.
Enforce SLAs
Service-level agreements (SLAs) should be enforced during the testing procedures. This is particularly important for testing at an advanced stage, when the API is fully functional—it allows you to identify any performance issues. This will also help you prevent the breach of SLAs.
Don’t Neglect Security Tests
API security is a critical concern at most organizations. APIs are used for mission critical applications and can potentially expose sensitive data, and result in damaging service disruption in case of an attack. Therefore, consistently testing for security vulnerabilities is a critical part of your API testing strategy.
Bright has been built from the ground up with a dev first approach to test your web applications, with a specific focus on API security testing.
With support for a wide range of API architectures, test your legacy and modern applications, including REST API, SOAP and GraphQL.
To compliment DevOps and CI/CD, Bright empowers developers to detect and fix vulnerabilities on every build, reducing the reliance on manual testing by leveraging multiple discovery methods:
- HAR files – watch video
- OpenAPI (Swagger) files – watch video
- Postman Collections – watch video
Start detecting the technical OWASP API Top 10 and more, seamlessly integrated across your pipelines via:
- Bright Rest API
- Convenient CLI for developers
- Common DevOps tools like CircleCI, Jenkins, JIRA, GitHub, Azure DevOps, and more
- Learn more in our detailed guide to api security testing tools
Start testing your applications and APIs with a FREE Bright account. With no false positives and developer friendly remediation guidelines Get a free Bright account and start testing!
