Hi Adam, At Tue, 17 Jul 2007 16:51:04 -0600, Adam Taft <[EMAIL PROTECTED]> wrote: > > Erik Hetzner wrote: > > I must have missed this in RFC 2616. How do you propose we tell the > > difference between a DELETE that does something & one that doesn’t? > > Why do you need to know? The fact that the resource is no longer > there satisfies the requirement for DELETE. > > If you MUST know, then follow it up with a GET, which will return a 404. > > Why do this? I had a hard time believing this was good advice until > thinking through this example: > > Two clients request a resource via GET. Then, they both send a DELETE > request at near the same time. The first client gets a 200 OK. The > second gets a 404 Not Found. Why should Not Found be reported to the > second client when his goal was to delete the resource? The goal was > satisfied. > > The goal of the DELETE operation is to change the state of the > resource. That's it. So long as this state change happens (or doesn't > happen), what else is there? There is no error. > > And, it makes the coding super duper easy. You don't have to check > for that mysterious 404 coming out of the server. > > Again, it's analogous to PUT. If two clients PUT a resource and both > of them make the exact same change such that the state of the resource > is what they both expect, is there an error? I say no. > > Make sense? I know this is more of one of those "controversial" REST > issues. But, I've come to know and love it. I hope you do too. ;)
You make some really good points; thanks for doing that. I wouldn’t put this in ‘should never’ land, however. It’s certainly not something that is clearly stated in RFC 2616. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
pgpwO5nZQKR8x.pgp
Description: PGP signature
