HTTP methods are used to indicate the action an API client would like to perform on a given resource. Each HTTP method maps to a specific operation, such as creating, reading, updating, or deleting a resource, and an HTTP method must be included with every request to a REST API.
HTTP protocol works by clients sending requests to the servers and servers responding to the requests. We do CRUD operations (Create, Read, Update, Delete) by sending HTTP requests with different HTTP methods, sometimes called HTTP verbs. GET and POST are the most frequently used HTTP methods, but more HTTP methods are to learn. This article will go through different HTTP methods and how to use them when building and using web APIs.
9 HTTP methods you should know about
1.GET Method
If we want to retrieve data from a resource like websites, servers or APIs, we send them a GET Request. For example, we send a GET request to the server if we want a list of our customers or a specific customer.
Since the GET method should never change the data on the resources and just read them(read-only), it is considered a Safe Method. Additionally, the Get method is idempotent.
How to test an API with a GET method?
When we want to test an API, the most popular method that we would use is the GET method. Therefore, We expect the following to happen.
If the resource is accessible, the API returns the 200 Status Code, which means OK.
Along with the 200 Status Code, the server usually returns a response body in XML or JSON format. So, for example, we expect the [GET] /members endpoint to return a list of members in XML or JSON.
If the server does not support the endpoint, the server returns the 404 Status Code, which means Not Found.
If we send the request in the wrong syntax, the server returns the 400 Status Code, which means Bad Request.
2.POST Method
The POST method creates a new resource on the backend (server). The request body carries the data we want to the server. It is neither a safe nor idempotent method. We don’t expect to get the same result every time we send a POST request. For example, two identical POST requests will create two new equivalent resources with the same data and different resource ids.
When sending a POST request to a server, we expect the following to happen:
Ideally, if the POST request has created a new resource on the other side, the response should come with 201 Status Code which means Created.
*Sometimes, performing a POST request doesn’t return a resource at the given URL; in this case, the method will return 204 status code which means No content.
**How to test a POST endpoint*
Since the POST method creates data, we must be cautious about changing data; testing all the POST methods in APIs is highly recommended. Moreover, make sure to delete the created resource once your testing is finished.
Here are some suggestions that we can do for testing APIs with POST methods:
Create a resource with the POST method, and it should return the 201 Status Code.
Perform the GET method to check if it created the resource was successfully created. You should get the 200 status code, and the response should contain the created resource.
Perform the POST method with incorrect or wrong formatted data to check if the operation fails.
3.PUT Method
With the PUT request method, we can update an existing resource by sending the updated data as the content of the request body to the server. The PUT method updates a resource by replacing its entire content completely. If it applies to a collection of resources, it replaces the whole collection, so be careful using it. The server will return the 200 or 204 status codes after the existing resource is updated successfully.
How to test an API with a PUT method?
The PUT method is idempotent, and it modifies the entire resources, so to test that behavior, we make sure to do the following operations:
Send a PUT request to the server many times, and it should always return the same result.
When the server completes the PUT request and updates the resource, the response should come with 200 or 204 status codes.
After the server completes the PUT request, make a GET request to check if the data is updated correctly on the resource.
If the input is invalid or has the wrong format, the resource must not be updated.
4.PATCH Method
PATCH is another HTTP method that is not commonly used. Similar to PUT, PATCH updates a resource, but it updates data partially and not entirely. For example, to make it more precise, the request [PUT] customers/{customerid} would update the fields in the Customers entity on the resource entirely. However, the PATCH method does update the provided fields of the customer entity. In general, this modification should be in a standard format like JSON or XML.
How to test an API with a PATCH method?
To test an API with the PATCH method, follow the steps discussed in this article for the testing API with the PUT and the POST methods. Consider the following results:
Send a PATCH request to the server; the server will return the 2xx HTTP status code, which means: the request is successfully received, understood, and accepted.
Perform the GET request and verify that the content is updated correctly.
If the request payload is incorrect or ill-formatted, the operation must fail.
5.DELETE Method
As the name suggests, the DELETE method deletes a resource. The DELETE method is idempotent; regardless of the number of calls, it returns the same result.
Most APIs always return the 200 status code even if we try to delete a deleted resource but in some APIs, If the target data no longer exists, the method call would return a 404 status code.
How to test a DELETE endpoint?
When it comes to deleting something on the server, we should be cautious. We are deleting data, and it is critical. First, make sure that deleting data is acceptable, then perform the following actions.
Call the POST method to create a new resource. Never test DELETE with actual Data. For example, first, create a new customer and then try to delete the customer you just created.
Make the DELETE request for a specific resource. For example, the request [DELETE] /customers/ {customer-id} deletes a customer with thee specified customer Id.
Call the GET method for the deleted customer, which should return 404, as the resource no longer exists.
Testfully’s Multi-step tests allow you to create resources on the fly and use them for testing DELETE endpoints.
6.HEAD Method
The HEAD method is similar to the GET method. But it doesn’t have any response body, so if it mistakenly returns the response body, it must be ignored. For example, the [GET] /customers endpoint returns a list of customers in its response body. Also, the [HEAD] /customers do the same, but it doesn’t return a list of customers. Before requesting the GET endpoint, we can make a HEAD request to determine the size (Content-length) of the file or data that we are downloading. Therefore, the HEAD method is safe and idempotent.
How to test a HEAD endpoint
One of the advantages of the HEAD method is that we can test the server if it is available and accessible as long as the API supports it, and it is much faster than the GET method because it has no response body. The status code we expect to get from the API is 200. Before every other HTTP method, we can first test API with the HEAD method.
7.OPTIONS Method
We use This method to get information about the possible communication options (Permitted HTTP methods) for the given URL in the server or an asterisk to refer to the entire server. This method is safe and idempotent.
Various browsers widely use the OPTIONS method to check whether the CORS (Cross-Origin resource sharing) operation is restricted on the targeted API or not.
How to test an OPTIONS endpoint
Depending on whether the server supports the OPTIONS method, we can test the server for the times of FATAL failure with the OPTIONS method. To try it, consider the following.
Make an OPTIONS request and check the header and the status code that returns.
Test the case of failure with a resource that doesn’t support the OPTIONS method.
8.TRACE Method
The TRACE method is for diagnosis purposes. It creates a loop-back test with the same request body that the client sent to the server before, and the successful response code is 200 OK. The TRACE method is safe and idempotent.
The TRACE method could be dangerous because it could reveal credentials. A hacker could steal credentials, including internal authentication headers, using a client-side attack.
How to test an API with a TRACE method?
Make a standard HTTP request like a GET request to /api/status
Replace GET with the TRACE and send it again.
Check what the server returns. If the response has the same information as the original request, the TRACE ability is enabled in the server and works correctly.
9.CONNECT Method
The CONNECT method is for making end-to-end connections between a client and a server. It makes a two-way connection like a tunnel between them. For example, we can use this method to safely transfer a large file between the client and the server.
Comparison of HTTP methods
Method Summary CRUD Accepts Request Body Idempotnent Safe
GET To fetch a single resource or group of resources Read No Yes Yes
PUT To update an entire resource in one go Update Yes Yes No
POST To create a new resource Create Yes No No
PATCH To partially update a resource Update Yes No No
DELETE To delete a resource Delete No Yes No
OPTIONS To get information on permitted operations Read No Yes Yes
HEAD To get metadata of the endpoint Read No Yes Yes
TRACE For diagnosing purposes Read No Yes Yes
CONNECT To make the two-way connection between the client and the resource. - No
Top comments (0)