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. ;)
Adam
