9 HTTP methods and how to use them

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.

Table of Contents

HTTP Request Structure

Before jumping into various HTTP methods and how to use them when building or using APIs, let’s go through a standard HTTP request structure. In HTTP protocol, every request should have a URL (Uniform resource locators) or URI(Uniform Resource Identifier) address and a method. An HTTP client sends an HTTP request to a server in the form of a request message which includes the following format:

• A request-line
• Zero or more Header (General|Request|Entity) field followed by CRLF.
• An empty line (a line with nothing before CRLF shows the end of the fields)
• A message-body (optional)

Using HTTP methods in Restful API development

REST is the abbreviation of Representational State Transfer, and it is an architectural pattern for creating web services. Web services that use the REST principles are the RESTful web services. These web services are used by application developers widely because they simply communicate with other servers on different machines.

REST makes it easy to share data between clients and servers. REST applications use HTTP methods like GET, POST, DELETE, PUT, etc., to do CRUD operations.

What is a Safe HTTP method?

A safe method is a method that doesn’t change data on the server. For example, GET and HEAD are safe methods because the user or an application does not request side effects on the server when calling them.

What is an Idempotent method?

An Idempotent method means no matter how many times it runs; it always returns the same response. For example, The PUT and DELETE methods share this property. However, it is possible that a sequence of several requests is not idempotent even if all of the methods executed in that sequence are idempotent. So, a series of requests is idempotent if a single execution of the entire series always returns the same result.

9 HTTP methods you should know about

By now, you have a good understanding of how HTTP protocol works, different HTTP methods, and why we should use them. This section will cover each method in more depth, so without further ado, let’s get started with GET, the most popular HTTP method out there.

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.

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.

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.

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.

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.

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.

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.

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.

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

Browser Support

Old browsers only supported the GET and POST HTTP methods. Nowadays, most modern browsers like IE, Firefox, Safari, Chrome, Opera support all standard HTTP methods.