Re: #331: clarify that 201 doesn't require Location header fields

Maybe I'm nitpicking, but I'd like to see it be more general; i.e., other methods could, in theory, be defined to use 201 without a location (although I'd grant this is unlikely).

It's also a bit wordy, currently.

Suggest:

"""
The request has been fulfilled and has resulted in one or more new resources being created.

Newly created resources are typically linked to from the response payload, with the most relevant URI also being carried in the Location header field. If the newly created resource's URI is the same as the Effective Request URI, this information can be omitted (e.g., in the case of a response to a PUT request).
"""

On 08/03/2012, at 12:27 AM, Julian Reschke wrote:

> Hi there.
> 
> From the bug:
> 
>> "The newly created resource can be referenced by the URI(s) returned in the payload of the response, with the most specific URI for the resource given by a Location header field."
>> 
>> Some people read this as a requirement to include "Location". At least for PUT->201 that's nonsense, however.
> 
> Proposed change:
> 
> 7.2.2.  201 Created
> 
>   The request has been fulfilled and has resulted in a new resource
>   being created.  The newly created resource can be referenced by the
>   URI(s) returned in the payload of the response, with the most
>   specific URI for the resource given by a Location header field.  For
>   a PUT request, the URI of the newly created resource is the effective
>   request URI, and thus the response does not need to carry any
>   additional information.
> 
>   The response can include a payload containing a list of resource
>   characteristics and location(s) from which the user or user agent can
>   choose the one most appropriate.
> 
>   (...)
> 
> 
> (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/331/331.diff>)
> 
> Feedback appreciated, Julian
> 

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

Received on Thursday, 8 March 2012 00:42:21 UTC