W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: Redirection after DELETE?

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 14 Nov 2006 15:52:01 -0800
Message-Id: <E1F996EA-38D9-4F4A-A1A2-EF45AF2B6034@gbiv.com>
Cc: ietf-http-wg@w3.org
To: Jan Algermissen <jalgermissen@topicmapping.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:53 GMT