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

On Feb 22, 2005, at 11:49 AM, Julian Reschke wrote:
> 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.

The client doesn't need to know.  An HTTP client does not know the
reason why a request is being made, just as it does not know the
text inside the anchor of a hypertext link that was clicked on to
generate a GET request.  The user (agent) builds up state based on
a huge number of factors, including what is said in all past
representations received, degrees of trust, instructions that
may have been received via some other channel, configuration, etc.
That is what tells the user what to expect.  HTTP doesn't care.
What HTTP cares about is that the method is unsafe, the response
is not (by default) cacheable, a new resource has been created (201),
and it can be found at a given Location.

> 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.

Completely irrelevant -- COPY and MOVE are HTTP operations on any
collection, not just webdav collections, and will succeed or fail
regardless of whether the client previously checked its pacifier.

> I'm not sure why this is a problem; and in particular I'd like to know 
> what a better solution would have been.

There was no problem -- it was a solution to someone's angst.

>> 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 completely unnecessary in HTTP.

>> [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.

Sorry, I meant MKWORKSPACE.

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

It could have been, but MKCOL was defined instead (over my objection).

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

Different URLs (see, for example, how the configurable name "index"
is a member of a collection and also the default response to GET
on that collection).  How a PUT or POST or any other method applied
to the collection is handled is just as configurable and may depend
on other aspects of the request (like content-type, authentication,
and more).  PUT is usually redirected to the index URL because
namespace operations are typically done one name at a time rather
than entire collections at a time, however that is dependent on the
implementation: when a client does a PUT of an XML document to a
JCR-backed implementation, it will create a collection (a document
is just one view of the collection).

Each resource has an implementation and that implementation defines
how the method impacts its state aside from what is already defined
by virtue of HTTP's method semantics.  The reason we don't need
ADDMEMBER is because POST already exists, a server must inspect
the media type already, and none of the overlapping uses of POST
are valid new members to add to a collection (soap envelopes or
www/x-form-urlencoded).  It is therefore possible to say that POST
has the add member effect on a webdav collection and be done.

....Roy

Received on Tuesday, 22 February 2005 21:02:09 UTC