Re: PUT, DELETE vs. POST

Larry wrote:
>"PUT and Derived-From with magic Content-Version" and "PUT and
>If-Valid with magic null validator" are less magic than "POST with
>magic posted data"?

First, maybe we need to replace the idea of "magic" with the idea
that an URI is *always* in a well-defined state, rather than being
in an indeterminate state if it "does not exist".  This removes the
boundary conditions upon creation or deletion of a resource.

Secondly, yes, they are less magic, as your next question points out:

>Does "POST" allow a "Modifies: URI" response header?

In the WG, we've gone around several times over the issue of what
constitutes a cache-key, both for caching and for content-negotation.
In this case, I have to say that I think it simplifies our job
tremendously if updates to the data store can follow the same semantics
as other requests.

Determining which entity may be affected by a request should be a
well-defined function of the URI and headers*, which is not the case
if one has to go grubbing around in POST fields, especially since the
general POST request probably has no effect upon the internal state of
the web.

The best analogy I can come up with at the moment is the distinction
between memory addresses and I/O addresses in a processor system.  It
makes the system architects (both hardware and software) job much
easier to maintain that distinction, since memory can be cached, mapped,
etc. in a semantically transparent manner, and I/O space allows one
to retain all of the more complex functionality for which one might wish.

-Dave

* this also implies that new/unknown methods can be treated in a very
  orthogonal manner, for caching, proxying, access control, etc.

Received on Wednesday, 13 March 1996 13:40:01 UTC