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

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