Top 5 Items to Test on a REST Based API

Recently, we discussed the value of shift-left testing for APIs and how to integrate APIs into your CI/CD pipeline. In today’s hyper-connected ecosystem, APIs are the bridge between your apps. And if an API fails (either during production or testing), it can compromise multiple apps, impact the user experience, and create chaos for IT teams. While many of you understand the importance of testing, it can be challenging to figure out exactly what you should be testing. Partially due to the sheer number of API testing solutions on the market, their respective complexity, and the fragmentation of various testing capabilities, pinpointing critical testing objectives isn’t easy.

Today, we’ll discuss the top 5 API functions you should be testing regularly. While there are other tests you could certainly run, these 5 shoulder the bulk of the responsibility.

1. HTTP Status Codes

When your API makes an HTTP request to a server, that server sends back status codes that indicate how well that connection was made, whether any errors were encountered, and some baseline details about the connection. This comes in the form of an HTTP status code. These API status codes come in five buckets:

• Informational responses (100 – 199)
• Successful responses (200 – 299)
• Redirects (300 – 399)
• Client errors (400 – 499)
• Server errors (500 – 599)

You want responses between 100 and 399. Any HTTP status codes that are 4x or 5x are considered errors, and something is impacting your APIs ability to respond with the server. We covered a few solutions to test this in our API testing automation guide.

2. Response Headers

HTTP response headers provide additional information about the connection, including authorization and authentication details. Not only does this make headers a valuable resource for building out APIs, but testing headers can reveal critical information surrounding the security and performance of your connections.

There are a few available solutions (e.g., Rest Assured, Postman, Newman, etc.) that automatically test headers, but your team will still need to manually solve any detected issues.

3. Response Payloads

Almost all APIs use JSON for data transfer. While you could technically use something like XML, it would require too much manual throughput, so we haven’t ever seen an organization work with APIs that aren’t using JSON. In fact, almost every framework automatically adds application/json to the header. So, validating your JSON values, field names, and types is a regular part of API testing. And you should always check for any error responses JSON shoots back to your app.

4. Performance

Smoke (and sanity) testing is an important part of the API testing workload. Often, smoke testing includes HTTP response testing, so these may be bucketed together in your automation solution. The goal of smoke testing is to check the overall performance of your API. For example, you may send large amounts of data through your API and calculate its speed. Once the smoke test is completed, you should test for the sanity of the results. In other words, does the performance and results of the data transfer work within the contexts of your solution? If not, something is wrong. If so, you can move forward.

5. Negative Testing

So far, we’ve only discussed how to ensure your API handles the correct data. But if the wrong data gets sent to your API? Does it crash? Or can it gracefully handle those invalid data points with an error message. This is super important. In the real world, your API will likely encounter some improper data at some point. You need to ensure it keeps functioning when that happens. Otherwise, that invalid data can crash your API and lead to serious frictions.