openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

Hi Mark,

On Tue, 2011-10-11 at 16:17 +1100, Mark Nottingham wrote:
> On 19/09/2011, at 4:03 PM, Mark McLoughlin wrote:
> 
> > OTOH, POST to update the object's metadata doesn't make much sense. We
> > don't "accept the entity enclosed in the request as a new subordinate".
> > PATCH[1] would probably have made more sense.
> > 
> > The spec is actually quite clear on the different between PUT and POST:
> > 
> >  "The fundamental difference between the POST and PUT requests is
> >   reflected in the different meaning of the Request-URI. The URI in a
> >   POST request identifies the resource that will handle the enclosed
> >   entity. That resource might be a data-accepting process, a gateway to
> >   some other protocol, or a separate entity that accepts annotations.
> >   In contrast, the URI in a PUT request identifies the entity enclosed
> >   with the request"
> > 
> > So, perhaps the guidelines should be:
> > 
> >  * Either POST or PUT creates things, depending on the meaning of the 
> >    request URI
> > 
> >  * PUT or PATCH modifies existing things
> 
> No, no, no.
> 
> The definitions of POST and PUT in RFC2616 are more harmful than
> helpful, and we (the HTTPbis WG in the IETF) have updated them; see
> 
>   http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.5
>   http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.6
> 
> In a nutshell, POST is "here, process this" while PUT is "store this
> here"; both can be used to create things (if they aren't there) or
> update things (if they are).
> 
> POST can do anything; there may be another method that has more
> specific semantics that are appropriate, but because of its
> escape-hatch nature, there really isn't anything it isn't allowed to
> do, semantically.

We're not attempting to enumerating all the valid ways that POST can be
used, we're trying to narrow down those possibilities to a set of
guidelines which describe the general style and idioms of OpenStack
APIs.

Cheers,
Mark.