1

Its mentioned on HTTP Spec that PATCH is not idempotent.

The basic definition of idempotent is:

An idempotent HTTP method is a HTTP method that can be called many times without different outcomes

So If we make an HTTP call

PATCH /users/1
{
    "username": "dummyUser"
}

No matter how many times we call above HTTP endpoint, it always implies to update the username of user 1 to dummyUser.

And that's pretty much same for any PATCH request to update 1 or many attributes of any resource.

Then why does HTTP Spec specify that PATCH is not idempotent?

Nazar Hussain
  • 5,102
  • 6
  • 40
  • 67
  • (a) Your example for PUT does not update just the username, it *replaces* the whole resource with the payload. (b) For PATCH it depends on what the patch semantics for the payload's media type are. – Julian Reschke Jun 12 '18 at 19:52
  • Just updated the question description. It was supposed to be patch in the snippet. – Nazar Hussain Jun 12 '18 at 19:57
  • There's still no media type (Content-Type) in the example, so it's impossible to say what PATCH is supposed to do here. – Julian Reschke Jun 12 '18 at 20:54

1 Answers1

7

Firstly, it's important to clarify that Idempotent: No doesn't mean it's never, ever idempotent, it means it's not necessarily idempotent, i.e. it isn't required to be.

So, in your example, it does seem to be idempotent, as the state of the resource is identical after multiple repeated calls of the same PATCH request.

But consider a hypothetical PATCH request like:

PATCH /users/1

successful_logins++

This request increments the successful_logins attribute of the user by one each time it's called. As you can see, it's not idempotent, since successive requests cause additional modification to the resource.

This is in contrast to the PUT method, which would have to contain the absolute values of all the resource's attributes.

e.dan
  • 7,275
  • 1
  • 26
  • 29