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

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 13:25:33 UTC