HTTP Methods : PUT vs POST vs PATCH

PUT ,POST and PATCH are three widely used HTTP methods .

But there still exists a lot of confusion , when it comes to ideal implementation of each of them .

Lets start our discussion with PUT

PUT should be used when the client (who is making request) is sending data to the server and the client is determining the URI for the resource.

To explore more let’s consider these scenarios
Suppose we make a PUT Call like this

https://www.abcxyz.com/apis/rest/message/10

METHOD=HTTP.PUT

{ _put_body : {payload_data}}

SCENARIO 1)

There is no message specific to id/identifier → 10
Here
It will create a new resource and assign it id → 10.

It will return a RESPONSE CODE OF 201 (Created)

SCENARIO 2 )

There exists a message resource with id/identifier → 10

SCENARIO 2.A

1)We need to navigate users to a new Page after PUT Request Completion

Here

It will update the existing resource with id →10 with the _put_body content it got.

It will return a RESPONSE CODE OF 200 (OK)

SCENARIO 2.B

1)We dont need to navigate users to a new Page after PUT Request Completion

Here

It will update the existing resource with id →10 with the _put_body content it got.

It will return a RESPONSE CODE OF 201 (OK)

In either of the scenarios or sub-scenarios even if we make a duplicate request subsequently

It is not going to affect anything on the RESOURCE line up on the server .

PUT request should always be preceded by a GET request to the resource, and should succeed if and if only resource hasn’t changed since.

So initial State of Resource is maintained . So PUT is IDEMPOTENT .

POST :-

In case of POST , client just sends the body of the request , and server creates the resource on the server and associates an id/identifier to the newly created resource (which can be a custom id based on your business requirements) and will generate URI for the newly created resource.

SO suppose we make a post request to generate a message

https://www.abcxyz.com/apis/rest/createmessage/ METHOD=HTTP.POST

{ _put_body : {payload}}

Here it will create a new resource and give it a id/Identifier

https://www.abcxyz.com/apis/rest/message/10

If we make a subsequent repeated request , It will go ahead and create a new resource with a new id/identifier → 11 .And the URI for new resource will be

https://www.abcxyz.com/apis/rest/message/11

Now this is unwanted behaviour .It just created a new duplicate resource with different URI

This can be seen as exploitation of RESOURCES line up on the server .

So we can’t make duplicate POST REQUEST .

So POST IS NON IDEMPOTENT

PATCH

HTTP.PATCH is used mainly for partial update .

PATCH request is intended to update just selective fields.

If we make multiple calls using PATCH , this could result into unexpected vunsatable changes in the resources state.

Hence it is not IDEMPOTENT.

Fore.g.:- There is a resource Message

Request 1: PATCH /message/1 {“creadted”: “PIYUSH”} — updates the creator of resource to be “PIYUSH”

Now suppose some other parallel request changes the state of resource, say

Request 2: PATCH /message/1 {“creadted”: “SUMIT”} — updates the age of resource to be created by “SUMIT”

Now if we sends the Request 1 again it would updates the resource again which is quite undesirable .

It can be made idempotent though using etags or If Modified Since headers.