At Tue, 17 Jul 2007 20:56:48 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > > Erik Hetzner wrote: > > […] ‘idempotent’ means repeating the operation ends up with the > > resource in the same state (it doesn't mean all the responses are > > always identical). > > What we're saying is that _because_ the resource is in the same state, > why wouldn't it ALWAYS return the same status code?
A counterexample. We have a resource which currently has ETag: "A". A conditional PUT is sent. This PUT has If-Match: "A". The first PUT modifies the resource & returns a 200; our new ETag is "B". We send the first request again; we receive back a 412, precondition failed. PUT has not been made non-idempotent by adding a precondition to it, even though our response is different. Idempotence is a property of the SIDE EFFECTS of a request (ie the changing of state on the server), not the RESPONSE. I think that you are correct in saying that returning a 204 is a good best practice on any DELETE. But this is not a requirement of the spec & it is not a requirement of idempotence as defined by the spec. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
pgpBkQdLe5p1I.pgp
Description: PGP signature
