CODEWITHSUNDEEP
resthttpput
Chenxi
Chenxi

Reputation: 87

A situation when HTTP put is not idempotent

Consider the following scenario:

  1. Alice updates item1 using http put
  2. Bob updates item1 using http put with different data
  3. Alice updates item1 using http put again with the same data accidentally, for instance, using the back button in a browser
  4. Charlie reads the data

Is this idempotent?

Upvotes: 0

Views: 295

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57259

Is this idempotent?

Yes. The relevant definition of idempotent is provided by RFC 7231

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

However, the situation you describe is that of a data race -- the representation that Charlie receives depends on the order that the server applies the PUT requests received from Alice and Bob.

The usual answer to avoiding lost writes is to use requests that target a particular version of the resource to update; this is analogous to using compare and swap semantics on your request -- a write that loses the data race gets dropped on the floor

For example

 x = 7
 x.swap(7, 8) # Request from Alice changes x == 7 to x == 8
 x.swap(8, 9) # Request from Bob changes x == 8 to x == 9
 x.swap(7, 8) # No-Op, this request is ignored, x == 9

In HTTP, the specification of Conditional Requests gives you a way to take simple predicates, and lift them into the meta data so that generic components can understand the semantics of what is going on. This is done with validators like eTag.

The basic idea is this: the server provides, in the metadata, a representation of the validator associated with the current representation of the resource. When the client wants to make a request on the condition that the representation hasn't changed, it includes that same validator in the request. The server is expected to recalculate the validator using the current state of the server side resource, and apply the change only if the two validator representations match.

If the origin server rejects a request because the expected precondition headers are missing from the request, it can use 428 Precondition Required to classify the nature of the client error.

Upvotes: 2

Егор Лебедев
Егор Лебедев

Reputation: 1336

Yes, this is idempotent. If it is wrong behavior for you, we should know bussiness logick behind that.

Upvotes: 0

Related Questions