- From: Jamie Lokier <jamie@shareable.org>
- Date: Wed, 16 Feb 2005 14:53:25 +0000
- To: Mark Baker <distobj@acm.org>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>
Mark Baker wrote:
> > This feature of HTTP is already defined as
> >
> > POST + media-type ==> 201 + location
>
> I was thinking the same thing Roy, but a new method would have the
> advantage of improved visibility; an intermediary observing a POST/201
> interaction wouldn't see anything in the POST request which licensed it
> to interpret that request as an attempt to store state, whereas a new
> method would provide exactly that license.
What kind of POST does -not- involve an attempt to store state?
RFC 2616:
POST is designed to allow a uniform method to cover the following
functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
I'm trying to imagine what you think an intermediary (or generic
client) would do with the proposed method differently from what it
would do with POST. They are both an attempt to modify state on the
server, and both potentially result in a created resource with a new URI.
I don't see how the intermediary is supposed to treat them
differently, so can you give an example?
-- Jamie
Received on Wednesday, 16 February 2005 14:53:55 UTC