I disagree, if you read the section from the link you just posted. This
clearly states that "the newly created resource can be referenced by the
URI(s) returned in the entity of the response, with the most specific URI
for the resource given by a Location header field.
The response should include an entity containing a list of resource
***characteristics and locations*** from which the user or user agent can
choose the one most appropriate.
10.2.2 201 Created
The request has been fulfilled and resulted in a new resource being
created. The newly created resource can be referenced by the URI(s)
returned in the entity of the response, with the most specific URI for the
resource given by a Location header field. The response SHOULD include an
entity containing a list of resource characteristics and location(s) from
which the user or user agent can choose the one most appropriate. The
entity format is specified by the media type given in the Content-Type
header field. The origin server MUST create the resource before returning
the 201 status code. If the action cannot be carried out immediately, the
server SHOULD respond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicating the
current value of the entity tag for the requested variant just created, see
section
14.19<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19>
.
On Wed, Dec 18, 2013 at 10:47 AM, Karel Piwko <kpiwko(a)redhat.com> wrote:
> To my understanding, HTTP 201 should always return created entity and its
> content should be based on Content-Type header field.
>
> See
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>
> On Mon, 16 Dec 2013 16:25:53 -0500 (EST)
> Vineet Reynolds Pereira <vpereira(a)redhat.com> wrote:
>
> > It would be better to treat this as a flag to be enabled during REST
> resource
> > scaffolding. It would allow users to choose how the resource behaves -
> > * send a 201 response with Location header,
> > * send a 201 response with Location header and also a response entity.
> >
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."