Hi Adam, At Wed, 18 Jul 2007 11:11:54 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > Right, but see, your resource changed from the first PUT request. > Therefore the Precondition Failed status code is appropriate. Again, > if a resource doesn't change, neither can its status code. The two > are linked together.
The point is, the state AFTER each request is processed is the same, but the status code is different. You have argued, w.r.t. DELETE, that as long as we have the same resource state after the request is processed, we must have the same response, whatever the previous state of the resource was (that is, either existing or not existing). But this is not in the HTTP spec, it is not a principle of REST, and it has nothing to do with idempotence. > If your resource hadn't changed in the first PUT request, then the > ETag wouldn't have changed, and therefore the second PUT wouldn't > result in a 412. > I'm not arguing the semantics of the spec, nor the strict definition > of "idempotent." You may be right on these technicalities. I'm just > saying what seems logical (at least to me), and that is one > shouldn't return two different status codes for a resource in the > same state. A logical conclusion of this principle would be that PUT should never return a 201 Created, because this depends on what the state of the resource was before the request was received. PUT should always return 200, because the state of the resource previous to the request is irrelevant. > Anyway, I'm glad you see the point about DELETE. Cheers to that. And thanks again for pointing it out. > Adam > > p.s. My last message was jumbled. Sorry, I was tired. ;) > > p.p.s John, thanks for the great insights. I truly appreciated your > messages. best, Erik Hetzner;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
pgpE5A6wP70j7.pgp
Description: PGP signature
