Idempotency

[mnot@…]

It *appears* that RFC3253 changes the idempotency of PUT; is this allowed? RFC3253 doesn't update or obsolete 2616...

I can see a situation where a 3253-naive client decides to retry a timed-out PUT (after all, it's idempotent) and gets some side effects it didn't bargain for.

[julian.reschke@…]

Discussed during the Prague meeting, see <​http://www.w3.org/2007/03/18-rfc2616-minutes.html#action10>: "Loosen definition of Idempotency as per Roy." -- See <​http://tech.groups.yahoo.com/group/rest-discuss/message/7387>: Just ignore the definition of idempotent in RFC 2616. Anything specified in HTTP that defines how the server shall implement the semantics of an interface method is wrong, by definition. What matters is the effect on the interface as expected by the client, not what actually happens on the server to implement that effect.

[fielding@…]

Replaced definition of idempotent with:

Methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect of multiple identical requests is the same as for a single request. The methods PUT, DELETE, and all safe methods are idempotent. It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state due to multiple requests for the purpose of tracking those requests, versioning of results, etc.

in [657].