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(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.
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev