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

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