[Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
julian.reschke at gmx.de
Tue Feb 22 11:49:50 PST 2005
Roy T. Fielding wrote:
> 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.
Agreed. But for POST, this only seems to work where there is a tight
coupling between client and server; otherwise the client will have no
clue about the server will indeed do with the request.
> 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
Well yes; let's take a look at WebDAV collections, part of the WebDAV
requirements written down in RFC2291
By defining a way to discover WebDAV collections
(DAV:resourcetype/DAV:collection in PROPFIND response), a client can
find out whether a resource is a WebDAV collection or isn't. Also,
WebDAV defines COPY and MOVE as namespace operations that take
containment into account.
I'm not sure why this is a problem; and in particular I'd like to know
what a better solution would have been.
> 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.
Right, those are moronic implementations (because in general, a client
can safely try the method and then handle HTTP's "method not allowed"
status code gracefully).
On the other hand, using distinct methods allows to use a
discovery/failure signalling approach that uses plain HTTP (OPTIONS
method, "Allow" response header, 405 status).
> [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.]
Nit: Versions aren't special resource types.
> 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".
Why can't a collection be PUT-able?
> 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.
OK, so that sounds to me like resources should fall into distinct
(A1) Collections vs (A2) Non-Collections
(B1) Put-able vs (B2) Non-Put-able
- resources of type A1 would understand POST request as having
- resources of type A2 can (within reason) do anything they like with
POST (as long as compliant to RFC2616)
- resources of type B1 will allow PUT (as defined by RFC2616) and
understand POST as "append" operation
Let's consider a simple WebDAV server that supports only resources of
types A1 and B1. What's the recommendation to do authoring operations
beyond PUT on these resources? Define new methods (such as
VERSION-CONTROL) or mint new related URLs to which existing methods can
Best regards, Julian
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
More information about the Ietf-caldav