Understanding HTTP request methods

There are 9 distinct methods to choose from when deciding to send an HTTP request to a server, but what are their differences, their uses, their features, and are they all useful?

Let's find out together!

In this article, I mention the concept of idempotence. If you're not familiar with it, I invite you to read my article dedicated to it!

The 9 HTTP Methods

GET

As its name suggests, GET is a method for retrieving a resource/information. It's the simplest of the methods; it should not contain a body, but the response usually does contain one.

May be cached, and must be idempotent.

POST

The POST method is used to create a resource. The data can be present in the URL parameters, or in the body of the request.

Note that the success of a POST request will often generate a 201 (Created) response, instead of the traditional 200 (Success).

No cache, and generally non-idempotent (unless there is a uniqueness constraint on the resources being created)

PUT

PUT requests are very similar to POST requests, but for updating a complete resource, instead of creating it from scratch.

The real differences with POST are that the return status is 200, and that the operation must be idempotent.

No cache, idempotent.

PATCH

Same use as PUT, but PATCH has a specific semantic for partial updates only, and is potentially non-idempotent.

Use cases can be found, for example, in adding a resource to an existing list. PUT would reset the entire list (with or without objects inside), while PATCH would add an object.

No cache, not necessarily idempotent.

DELETE

Same as PUT, but for deleting an entity, and without a body in the request (all information must be passed in the headers or the URI).

The response can nevertheless contain a body, with the deleted resource for example.

No cache, no body, idempotent

OPTIONS

An OPTIONS request is what's called a "pre-flight request".

It's what allows the client to ensure that the upcoming request it's about to send meets the constraints set by the server (available content type, access rights, etc.). It is (often) sent automatically by the client before a request that contains a body such as POST, UPDATE, and DELETE.

Must not be cached, even though it is idempotent.

HEAD

We use the GET method to retrieve the "raw" data linked to a URL, while we'll use the HEAD method to retrieve the "metadata" linked to the resource or file instead.

This can be used, for example, to check if a link is still valid, or to retrieve the format/size of a file that one might want to download later.

HEAD can be cached, and neither the request nor the response should contain a body, everything goes through the headers.

TRACE

This method is exclusively reserved for debugging the web server; its sole purpose is to verify that requests are properly received and responses properly sent.

In normal operation, each message received is simply sent back as-is, with the headers:

• Content-Type: message/http
• Via: Trace of the route the request followed (server, proxy, etc.)

TRACE = No cache, not used in typical web development use cases

CONNECT

Not really used as a classic HTTP method, CONNECT allows an HTTP proxy to be used as a tunnel (TCP for example).

To go further

All these methods are documented in section 9 of the RFC describing how the HTTP 1.1 protocol works. To learn more, I invite you to go read this documentation, accessible here: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

In the series on HTTP, I invite you to read my article on the main response codes and their meanings