- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 14 Nov 2006 15:52:01 -0800
- To: Jan Algermissen <jalgermissen@topicmapping.com>
- Cc: ietf-http-wg@w3.org
On Nov 14, 2006, at 2:57 PM, Jan Algermissen wrote: > is it appropriate for a server to return a redirect (as opposed to > 401/410) after a resource has been DELETED? You mean redirect future GET requests on that resource, right? > (set aside the case that the resource can be updated with PUT at > any time in the 401 case). > > (REST at least seems to suggest 'no' to the question since a > redirect is not an empty membership function) Er, just about any claim that is made about two independent requests is not supported by anything in REST. Just because a resource is deleted one second doesn't mean the server can't create something in its place the next second. The important bit for HTTP is that the client expresses its intention in the request (DELETE) and the server expresses its intention on the response (200). After that point in time, any client that assumes some state exists or does not exist on the server because of its own interactions is inherently broken, unless there is some form of exclusive access control or locking in effect (and even then it is just bad design to assume a closed universe). Most clients can safely assume that a server will perform the intended action, since there is no reason not to if the parties have already given authorization to perform the DELETE. The actual effect of a DELETE on the underlying storage and on other resources on the server is none of HTTP's business. ....Roy
Received on Tuesday, 14 November 2006 23:51:59 UTC