- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 10 Mar 2012 13:34:00 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2012-03-09 10:16, Julian Reschke wrote: > On 2012-03-08 01:41, Mark Nottingham wrote: >> 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). >> """ >> ... > > I like this better, but it makes another change (talking about multiple > resources being created) that we haven't discussed before; I believe > this should go into a separate issue... > > Rephrased proposal: > > 7.2.2. 201 Created > > The request has been fulfilled and has resulted in a new resource > being created. > > The newly created resource is 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). > > (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/331/331.2.diff>) Hearing no objections: <clarify that 201 doesn't require Location header fields> I have also created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/347> to track the other issue (more than one resource being created). Best regards, Julian
Received on Saturday, 10 March 2012 12:34:33 UTC