What is Idempotent HTTP Method?

Idempotency - Overview

Idempotency is a very popular term in HTTP verbs. Before we go ahead with each method, let us understand what is Idempotency? A HTTP method is Idempotent if the intended effect of making a single request on the server is same as the effect of making several identical requests. In other words, it guarantees that performing the operation multiple times will yield the same result as if it was executed only once.To summarize, it basically does not have any side-effects on the server or resource. Only the first request has an effect on the server and subsequent requests sent later have no effect..

As a mathematical example, adding a zero to any number will basically have no effect on the number, or rotating something 360 degrees.Both of these examples describe an operation that is idempotent.

What is a Safe HTTP Method?

HTTP methods are considered safe if they do not alter the state of the server. So safe methods should be used for read-only operations and not write operations.

Idempotency and HTTP Requests

When we say Idempotent HTTP requests, it means safe and reliable trying of the requests without accidentally duplicating or repeating entries of the same request.

To perform an idempotent request, a unique idempotency key must be provided to the server along with the request options. The server uses this key to recognize and distinguish subsequent retries of the same request.Non-idempotent operations can have different results.

Now that we understood the concept of Idempotency in HTTP verbs, let us take a walkthrough of each method individually and understand it’s behavior

While there are around a dozen of available HTTP methods, most services deal primarily with the 4 CRUD operations: POST, GET, PUT, and DELETE.

Let's have a look at which HTTP Methods are Idempotent and which are not.

HTTP POST

POST represents ‘C’ for ‘Create’ in the CRUD operations. The primary purpose of the POST method is to create a new resource. It is often employed when submitting form data, uploading files, or sending JSON payloads to the server.

POST request is non-Idempotent, meaning sending two identical POST requests might result in duplicate entries of the same resource. POST URI often points to the resource collection where a new resource is to be created. Usually, in POST requests we cannot have predictable outcomes.

POST method is not safe. Since POST requests alter the state of the server by creating a new resource, it’s considered as not safe.

HTTP GET

GET represents ‘R’ for ‘Read’ in the CRUD Operations

This request is primarily used to read or request a representation of a specified resource.

GET requests are Idempotent as they’re read-only methods and hence subsequent identical requests to the server for the same resource do not create any side-effects on the server.

The GET method is safe, as it does not alter the state of the server.

HTTP PUT

PUT represents ‘U’ for ‘Update’ in the CRUD operations

This request is primarily used to update/modify the entire resource with the data that is passed in the body payload (In some implementations, it creates a new resource if the resource does not already exist, though not a recommended practice).

The URI of PUT requests mostly specifies the unique ID of the resource to be updated using which server locates the exact resource from the resource collection.

PUT request is Idempotent because of its ability to modify the resource's entire content. Since the client is providing the complete representation of the resource (i.e. complete payload data), the server can update the resource to the exact same state as many times as needed without any unintended side effects. Therefore, we can send the same PUT request multiple times with predictable outcomes.

The PUT method is not safe as it alters the state of the server by modifying the resource.

HTTP DELETE

DELETE represents ‘D’ for ‘Delete’ in the CRUD operations. It requests the deletion of a specific resource represented by a unique ID sent as URI (Uniform Resource Identifier).

Delete requests are Idempotent as sending multiple delete request for the same ID will result in the same outcome. Only the first delete request will have an effect on the server by deleting the requested resource and any subsequent delete request will not have any side-effects on the state of the server as the resource is already deleted.

Delete request is not safe, as it is altering the state of the server by deleting the specified resource in the first request.

HTTP PATCH

PATCH also represents ‘U’ for Update/Modify in the ‘CRUD’ operations.

The PATCH request is primarily used to modify/update partial details of the resource. Here, the client need not send entire details of the resource to be modified, rather only the specific details that need modification can be sent as Payload in the Patch request, without affecting any other attributes of the resource.

Patch request is non-Idempotent (although it can be Idempotent) and the idempotency basically depends on how one wants to change the resource and implementation on the server side. For example, if the Patch request wants to move the resource, in this case the first request will perform the desired modification but subsequent identical Patch request might have side-effects on the server as the desired movement is already done. Patch requests may have side-effects on other resources as well.

The PATCH method is not safe, as it alters the state of the server by updating the specified attributes of the resource.

HTTP Verbs Overview

Till now we have seen various HTTP methods and their behavior with respect to idempotency, below table summarizes this:

HTTP METHOD	IS IDEMPOTENT?	IS SAFE?
POST	No	No
PATCH	No	No
GET	Yes	Yes
PUT	Yes	No
DELETE	Yes	No

Conclusion

So now that we know what is Idempotency and the overview of major CRUD operations. A question might strike your mind, as to why Idempotency is so important in HTTP methods? An idempotent operation can be safely transmitted or re-tried without any additional side effects. Consider an environment with network latency, often experiencing network slowness. Here there are high chances that the same request might be sent multiple times erroneously creating unintended side-effects on the server and thereby creating additional resources or modifying them, causing unexpected changes on the server side.

As accuracy of data is an important aspect of any business, non-idempotency can pose a significant risk on businesses.

Thus, Idempotency is very crucial to maintain consistency, better Fault Tolerance API and Error Handling.

Hope, you find this information useful. Happy HTTPing!