- From: Mark Baker <distobj@acm.org>
- Date: Fri, 25 Feb 2005 00:35:09 -0500
- To: HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, WebDAV WG <w3c-dist-auth@w3.org>
On Wed, Feb 23, 2005 at 12:24:07AM -0800, Roy T. Fielding wrote: > On Feb 22, 2005, at 8:26 PM, Mark Baker wrote: > >I still don't see how POST vs. ADDMEMBER is any different than POST > >vs. PUT. You previously said that PUT has "set the state of this > >resource" semantics which is clearly different than POST. IMO, > >ADDMEMBER's semantics are very similar to PUT. What (constraint?) am > >I missing that suggests PUT is fine while ADDMEMBER isn't? > > You are missing that the target of PUT is the new resource, > whereas the target of POST and ADDMEMBER are both the collection > resource. As such, ADDMEMBER's semantics has very little in > common with PUT (almost nothing, in fact, since any unsafe > extension method can return 201 and communicate just as much, > whereas PUT is unique in what it communicates by the 200/201). In case anybody's still following this thread 8-) ... I now find myself in agreement with Roy, that POST is appropriate and that ADDMEMBER == POST. I was looking at the interaction from the POV of a tweak on PUT semantics, rather than as the submission of a document to a state-preserving container (which I should have recognized it as immediately, given my previous attempts at describing such a model[1]). I'm still not convinced that a POST extension (which declared the expected type of the target resource) wouldn't improve the self-descriptiveness of the message, but practically, that's pretty much irrelevant for the purposes of this discussion. [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Friday, 25 February 2005 06:04:17 UTC