It sounds like, at a minimum, we have a bug in the Forge scaffolding to support Aerogear.js
My next concern would be that since this "feature" was introduced with jQuery 1.9, it could be that a LOT of the world's REST endpoints are no longer POST compatible with Aerogear.js, nothing to be done about that except to document it well for Aerogear.js when the time to promote it heavily comes up.
Aerogear.js doc issues also include confusion of datamanager/store (getting started guide is not clear for when those are needed) and the seemingly missing docs for Pipe. Plus, the first example seen by the end-user should include the use of iteration through the results, not an underscore template which hides some of the details.
On Dec 18, 2013, at 10:47 AM, Karel Piwko <kpiwko@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)
>> 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.
>>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev