API Testing 101: HTTP Verbs And How To Test Them

APIs are everywhere in modern applications, and for a modern software tester, API testing is a must-have, and these days REST is the most commonly used type of API out there.

But many testers, especially those new to API testing, overlook the intent behind the HTTP verbs used in the API architecture.

See, developers don’t always use the correct or consistent HTTP verbs in their APIs. And this can lead to trouble later on, with subtle bugs or APIs that don’t scale well.

In short, semantics are something worth checking, and something you should question critially as a tester whenever you reveiw a new API.

What’s an HTTP Verb?

HTTP verbs are the foundation of RESTful APIs and play a crucial role in determining the intent and function of each API endpoint.

For example, imagine you have an API for your customer database. You might have several endpoints to create a new customer, retrieve customer information, update customer details, and delete a customer.

The HTTP verb used with each endpoint conveys its intent and function, with common verbs such as GET, POST, PUT, and DELETE being used to perform common actions like retrieving data, creating new data, updating data, and deleting data respectively.

So to retrieve the details for a particular customer, you would use a GET, like this:

GET /customers/{id}        

Whereas to update the customer’s email, you might need to use a PUT to send a JSON payload to the?/customers?endpoint:

PUT / customers
{
  "firstName": "Jane",
  "lastName": "Doe",
  "email": "[email protected]"
}        

Proper use of HTTP verbs in a REST API not only makes the API easier to understand and use, but also ensures that it is scalable, secure, and easy to maintain.

So how do you test HTTP verbs?

Here is a checklist of the main HTTP verbs and their intent, along with some concrete examples of what should be tested for each verb, using an API that creates customers and customer orders.

GET

GET is all about reading. Its purpose is to be a read-only operation. This means that when you use GET, the state of the system should not change, no matter how many times you perform the same operation. This is what we call idempotent — you can do the same thing over and over again and the result should always be the same.

So what might you check for our Customer API for a GET endpoint? Here are a few ideas:

Examples of what to test for GET:

• Does it work for a single record? Check that a GET request to /customers/{id} returns the correct customer information for a given customer ID
• Does it work for multiple records? Check that a GET request to /customers returns a list of all customers in the system
• Does it work for missing records? Check that a GET request for a non-existant customer returns a 404 error.
• Is it idempotent? Check that multiple requests to /customers/{id} return the same customer information
• Does it return the correct status code, e.g. 200 for successful queries, and 404 for a non-existant customer id

POST

POST is all about creating new resources. But here’s the thing — it’s not idempotent. This means that if you use it more than once, you could run into some unexpected issues. So you’ll need to make sure to only use it once for each new resource you want to create.

Examples of what to test for POST:

• Does it create a new record? Check that a POST request to /customers creates a new customer in the system and returns the correct status code (e.g. 201 Created)
• Does it create a new record each time? Check that repeated POST requests to the same resource create multiple instances of the resource (e.g. multiple customers with the same information)
• Does it reject duplicates when it should? Check that it doesn’t allow you to create a customer with the same email twice.

PUT

PUT is all about updating things that already exist. The good news is that it is idempotent, which means that if you perform the same operation multiple times, it should have no effect on the system. So, feel free to update away! Just know that you can repeat the operation as many times as you need to without worrying about any unintended consequences.

Examples of what to test for PUT:

• Check that a PUT request to /customers/{id} updates the existing customer information for a given customer ID and returns the correct status code (e.g. 200 OK or 204 No Content)
• Check that repeated PUT requests to the same resource do not create multiple instances of the resource (e.g. multiple customers with the same updated information)

PATCH

PATCH is less commonly used, but you still see it out there from time to time. It’s used for partially updating existing resources. However, it is not idempotent, meaning that if the same operation is performed multiple times, the state of the system may change.

Examples of what to test for PATCH:

• Check that a PATCH request to /customers/{id} updates only the specified parts of the customer information for a given customer ID and returns the correct status code (e.g. 200 OK or 204 No Content)

DELETE

DELETE is used to delete resources. One fun fact is that DELETE is idempotent: for example if you call?DELETE /customer/123?multiple times, you will get the same result (customer 123 will not be in the system).

Examples of what to test for DELETE:

• Does it delete an existing customer? Check that a DELETE request to /customer/123 does indeed delete the customer
• Does it work if you delete the same customer twice?
• Does it return the correct response even if the customer does not exist?
• Does it respect security requirements (e.g. which users should be allowed to delete customers)

Conclusion

So there you have it folks, understanding and testing the meaning behind the HTTP verbs in REST APIs is a big part of API testing that shouldn’t be skipped over. When developers use the right verbs in their APIs, it makes it easier for everyone to use and understand. And when testers do their part by testing the verbs, they’re making sure the API is working as it should.