Subject: Redirection after DELETE?

From: Jan Algermissen <[email-masked]>
Date: Tue, 14 Nov 2006 23:57:35 +0100

Hi,

is it appropriate for a server to return a redirect (as opposed to  
401/410) after a resource has been DELETED?

(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)

Thanks,

Jan

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 14 Nov 2006 15:52:01 -0800

> 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