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

[Julian Reschke <[e-mail]>]

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 
(<http://greenbytes.de/tech/webdav/rfc2291.html#rfc.section.5.8>).

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 
categories:

(A1) Collections vs (A2) Non-Collections
(B1) Put-able vs (B2) Non-Put-able

- resources of type A1 would understand POST request as having 
"ADDMEMBER" semantics

- 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 
be applied?



Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]