Open Stack

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.

Cheers,

--
Mark Nottingham   http://www.mnot.net/