W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 22 Feb 2005 00:21:05 -0800
Message-Id: <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, WebDAV WG <w3c-dist-auth@w3.org>
To: Mark Baker <distobj@acm.org>

On Feb 21, 2005, at 7:46 PM, Mark Baker wrote:
> Let me ask this; why do we have PUT when a valid effect of a POST
> could also be to set the state of a resource?

Because PUT means set the state of this resource, whereas POST
does not.

> IMO, it's because there are advantages to having messages which reflect
> the expectations of their sender.

Umm, think about that sentence and you will find it has no content.
Messages reflect the instruction of the sender.  POST does that.

What you are really saying is that there are advantages to the
client knowing the nature of a resource, encoding that nature
into the set of methods used, and thus forcing how its state
will be impacted by each messaged action.  That is what Julian
wants in an ADDMEMBER method.  You, of all people, should
be the first to recognize that slippery slope.

Yes, it has advantages, but it also has far-reaching disadvantages
that HTTP was designed to prevent. It causes clients to become
coupled to particular "types" of resources on the server, which
is just another from of implementation-dependency.  It leads to
absolutely moronic implementations that have to test each resource
for the set of methods it implements before performing a set of
actions that would have the same result as a generic POST.
[Which is to say that it will suck every bit as much as the other
methods introduced by webdav and its prodigy that created arbitrary
resource types for collections, versions, and now calendars.]

POST, in contrast, is a generic semantic that allows the resource
to determine its implementation-specific effects.  POST to a
collection means add a member.  POST to a PUT-able resource means
an atomic append. POST to a messaging gateway means "post this".
POST to any other resource means "process this". Note, however,
that to a client they all mean the same thing: take this data
and apply it in accordance with your nature.  The client does
not need to know anything more because the client already knows
what it wants to do (and knowing more cannot help it, since
only the server is allowed to know the implementation).

PUT versus PATCH might lead you to an interesting comparison,
at least in terms of seeing when two methods do have different
semantics.  A better example is POST versus PATCH, given that
PATCHing a collection could be defined as a set of add/remove
operations on the collection state. One could easily define a
patch media type for that, but there are also good reasons not to.

POST versus ADDMEMBER, however, does not compare at all because
POST is already defined to be "add a member." POST only seems to
have multiple definitions because the other definitions are
examples of various forms of partial state change within a
resource that may consist of identifiable subcomponents. It is
really just one semantic definition that manifests in different
ways based upon how the implementer views the resource to which
the POST is applied.  A file is just an ordered collection of bytes.
A collection is just a file with a compound media type. A gateway
is just a pipe, and a pipe is just a file with scrolling-window
state over time.

The IETF could give every form of implementation a different
type and every type its own set of methods for manipulating
state, but all that will accomplish is the death of another
protocol.  And no, I don't care what SOAP does via POST,
since SOAP has already proven to be a miserable failure.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>
Received on Tuesday, 22 February 2005 08:26:11 GMT

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