As a software tester, we recognize that buggy software may be a programmer’s worst nightmare. This is why testing is such an important part of any software development process. Ever thought what’s the difference between GET and POST requests, or when to use PUT? You’re not alone. Having a basic understanding of the various HTTP methods, an API supports is an helpful knowledge when exploring and testing APIs.
What is API testing?
API testing is sort of software testing that involves testing the application programming interfaces (APIs) directly and as a part of integration testing to work out if they meet goals for functionality, performance, and security. Since APIs lack the GUI, API testing is performed at the message layer.
In this post, We’ll discuss how HTTP method is used and how to incorporate them in your API testing.
HTTP Methods
GET
POST
DELETE
PATCH
GET
GET requests are the most common and widely used methods in APIs and websites. The GET method is employed to retreive data from a server at the required resource. For example, say you’ve got an API with a /users endpoint. Making a GET request will endpoint should return an inventory of all available users.
Since GET request is only requesting the data and is not modifying any resources, it’s considered as safe method.
Testing an API with GET requests:
When you’re creating tests for an API, the GET method will likely be the most frequent type of request made by consumers of the service, so it’s important to check every known endpoint with a GET request.
At a basic level, these things should be validated:
Always Check valid GET request returns a 200 status code.
Ensure that a GET request to specific resource returns the correct data. Let’s take example, GET /emails/mailbox-keys returns a list of keys of a users.
GET is usually the default method in HTTP clients, so creating tests for these resources should be simple with any tool you select .
POST
POST requests are used to send data to the API server to create or update a resource. The data sent to the server is stored within the request body of the HTTP request. It mutates data on the backend server (by creating or updating a resource), as against a GET request which doesn’t change any data.
The simplest example is a contact form on a website. When you fill out the inputs during a form and hit Send, that data is put within the response body of the request and sent to the server. This may be JSON, XML, or query parameters (there’s many other formats, but these are the foremost common).
Testing an API with POST requests:
The second commonest HTTP method you’ll encounter in your API tests is POST. As mentioned above, POST requests are wont to send data to the API server and make or update a resource. Since POST requests modify data, it is vital to possess API tests for all of your POST methods.
Here are some tips for testing POST requests:
Create a resource with POST request and always ensure 200 status code is returned.
Make a GET request for that resource, and ensure the data was saved correctly. Let’s take example, POST /emails/mailbox-keys create a key pair of a users.
PATCH
A PATCH request is one among the lesser-known HTTP methods, but I’m including it this high within the list since it’s almost like POST and PUT. The difference with PATCH is that you simply only apply partial modifications to the resource.
The main difference between PATCH and PUT, is that a PATCH request is non-idempotent (like a POST request). To expand on partial modification, say you’re API features a users/{{userid} endpoint, and a user has a username With a PATCH request, you’ll only got to send the updated username within the request body – as against POST and PUT which require the complete user entity.
Testing an API with PATCH requests
Since the PATCH method is so similar to POST and PUT, many of the equivalent testing techniques apply. It is still important that we validate the behavior of any API endpoints that accept this method.
What to look for when testing PATCH requests:
A successful PATCH request should always return a 200 status code.
PATCH requests will get fail if any invalid data is supplied in the request — nothing will be updated.
Let’s take example, POST /emails/mailbox-keys/{id}/ update a key pair of a users with key pair id = {id}.
The semantics of PATCH requests will largely depend on the specific API you’re testing.
DELETE
The DELETE method is strictly because it sounds: delete the resource at the required URL. This method is one of the more common in RESTful APIs so it’s good to know how it works.
If any new user is created with a POST request to /users, and then it can be retrieved with a GET request to /users/{{userid}}, then making a DELETE request to /users/{{userid}} will destroy that user.
Testing an API with DELETE requests
DELETE requests should be properly tested since they generally remove data from a database. Be careful when testing DELETE methods, make sure you’re using the correct credentials and not testing with real user data as it can harm the data.
[“source=technoarchsoftwares”]
