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

Geoff,

it is certainly true that WebDAV has introduced new methods for almost 
everything. I sometimes feel however that reusing existing methods in 
some cases would have its benefits. A GETtable PROPFIND multistatus is 
one of them (with last-modified and etags maybe, yummy!).

In order to stamp out any meta discussion and can openers: the 
discussion about ADDMEMBER and POST seems to hint the POST was intended 
to do what ADDMEMBER addresses. The only thing that is missing is the 
auto discovery feature. That's why I injected my proposal here.

As with any architecture, you can build around small set of primitives 
or make lots of specifics. Finding the optimal balance is the fun 
thing. You cannot say: as we went that way in the past, it will only 
get better when we continue in that direction. Its not a linear 
topology or else software could easily optimize it for us...

//Stefan

Am 17.02.2005 um 15:03 schrieb Geoffrey M Clemm:

>
> The benefit of using a new method name to define a new method is that 
> you
> can re-use all of the existing machinery (both syntactic and semantic) 
> that
> keys off of the method name.  
>
> Although SOAP has gone down the "embed the method name in the body of 
> the POST"
> approach, WebDAV has taken the "use the method name as the method 
> name" approach.
>
> If you use some other technique (such as embedding the method name in 
> the
> request-URI), you need to re-invent new machinery to do all the same 
> things
> that the existing machinery does with method names.
>
> Cheers,
> Geoff
>
>
> Stefan Eissing <stefan.eissing@greenbytes.de> wrote on 02/17/2005 
> 08:25:05 AM:
>
>  > Geoff,
>  >
>  > i do not see a problem with introducing a new URI should the server
>  > wish to support POST for other purposes. Example:
>  >
>  > http://example.com/collection/
>  >
>  > supports POST for other purposes, then one solution is that
>  >
>  > OPTIONS /collection/ HTTP/1.1
>  > Host: example.com
>  >
>  > HTTP/1.1 200 Ok
>  > Allow: GET, HEAD, OPTIONS, POST
>  > WhatEverTheHeaderName: 
> http://example.com/collection/?function=AddMember
>  >
>  > Of course, in the case of embedding the Post service URI in a site
>  > description, there would be one URI for all resources belonging to 
> that
>  > site and the client is not able to control in which collection the
>  > resource will appear. But I do not see that as an issue...
>  >
>  > I see beauty in describing such functions inside a site description
>  > resource. It is cacheable again, it can habe ETags, it can be 
> target of
>  > conditional retrieval and it can even be authorable via WebDAV 
> should
>  > some crazy people want to do that.
>  >
>  > //Stefan
>  >
>  > Am 17.02.2005 um 14:04 schrieb Geoffrey M Clemm:
>  >
>  > >
>  > > Stefan: How does your proposal below address the problem of 
> performing
>  > > an addmember function against a resource that already interprets 
> POST
>  > > as meaning "execute the function specified in some special format 
> in
>  > > the body of this POST call".  You don't want to have to introduce 
> a new
>  > > resource just to perform an addmember function against that 
> resource.
>  > >
>  > > Cheers,
>  > >  Geoff
>  > >
>  > > Stefan wrote on 02/17/2005 07:58:58 AM:
>  > >  >
>  > >  > I think What Would Make The World A Better Place is a 
> mechanism that
>  > >  > generic clients can discover POST service points where they can
>  > > persist
>  > >  > new entities. There is nothing wrong with POST, it is just 
> that a
>  > >  > client cannot discover if and where a server supports that 
> feature.
>  > >  >
>  > >  > Atom solves this problem by embedding the POST service uri 
> into the
>  > >  > feed document. That is fine, but
>  > >  > a) has low reusablity for other protocols/applications
>  > >  > b) has no usability from the view of a generic client
>  > >  >
>  > >  >   I think this is what Julian tries to address with ADDMEMBER, 
> since
>  > >  > this method will  be visible in an OPTIONS response. 
> Alternatively,
>  > > an
>  > >  > OPTIONS reponse could carry an extra Header with the URI of 
> such a
>  > > POST
>  > >  > service.
>  > >  >
>  > >  > On second thought, this could also be nicely wrapped up inside 
> a
>  > > site
>  > >  > description and the pointer to the site could be a header in an
>  > > OPTIONS
>  > >  > response. Then a small, extensible site description document 
> (XML)
>  > >  > could do the job nicely.
>  > >  >
>  > >  > //Stefan
>  > >  >
>  > >  > Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm:
>  > >  >
>  > >  > >
>  > >  > > I believe the problem arises when you are trying to apply the
>  > >  > > addmember function to a resource that already handles POST as
>  > > meaning
>  > >  > > "do the operation specifies in the body of the POST".
>  > >  > > To use POST to perform an addmember to that resource, you 
> would
>  > >  > > need to have some special encoding of the addmember function 
> in
>  > >  > > the body of the POST.  But this special encoding only works 
> on
>  > >  > > resources that support that particular encoding for POST 
> calls.
>  > >  > > So that would mean that for a client to use POST to perform
>  > > addmember,
>  > >  > > it would need to know whether or not a resource already 
> interprets
>  > >  > > POST in a certain way, and then would need to know the 
> encoding in
>  > >  > > the body that would be understood by that resource as meaning
>  > >  > > "addmember".
>  > >  > >
>  > >  > > I may be missing something obvious here (and if so, I'm 
> counting
>  > > on
>  > >  > > Roy pointing it out :-), but if not, it seems that POST 
> cannot be
>  > >  > > defined to perform any particular operation, since it 
> already is
>  > >  > > being used by some resources to mean "perform the operation
>  > > specified
>  > >  > > in the body".
>  > >  > >
>  > >  > > Cheers,
>  > >  > > Geoff
>  > >  > >
>  > >  > > Roy wrote on 02/17/2005 12:54:16 AM:
>  > >  > >  >
>  > >  > >  > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote:
>  > >  > >  > > RFC 2616 states:
>  > >  > >  > > "The actual function performed by the POST method is
>  > > determined
>  > >  > > by the
>  > >  > >  > > server and is usually dependent on the Request-URI."
>  > >  > >  > >
>  > >  > >  > > From a client perspective this makes POST unreliable, 
> and
>  > > leads
>  > >  > > to the
>  > >  > >  > > desire to define a new method.
>  > >  > >  >
>  > >  > >  > The action will either succeed or fail.  If it succeeds, 
> the
>  > > client
>  > >  > >  > will receive the exact same response from POST that it 
> would
>  > > have
>  > >  > >  > received from a new method.  If it fails, the client will
>  > > receive
>  > >  > >  > the same potential set of failure responses as it might 
> have
>  > > from
>  > >  > >  > a new method.
>  > >  > >  >
>  > >  > >  > The only way you could claim that a new method would be 
> more
>  > >  > > reliable
>  > >  > >  > is if the client knows the exact implementation of the 
> resource
>  > >  > >  > being requested, which is something that a client does 
> not know
>  > >  > >  > with HTTP, and even if it did, it is far more likely that 
> it
>  > > will
>  > >  > >  > know how the server and all intermediaries will respond 
> to the
>  > >  > >  > existing POST method than it could know about their 
> response to
>  > >  > >  > a new method that has zero deployment.
>  > >  > >  >
>  > >  > >  > ....Roy
>  > >  > >  >
>  > >  > >  >
>  > >  >
>  > >  >
>  > >  >
>  >
>  >

Received on Thursday, 17 February 2005 16:04:48 UTC