On Wed, Dec 18, 2013 at 4:54 PM, Burr Sutter <bsutter(a)redhat.com> wrote:
It sounds like, at a minimum, we have a bug in the Forge scaffolding
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.
Before you used Aerogear, you had also a version using only jquery, right ?
Did you had the same behavior when doing a POST ? If yes, it's not
only Aerogear based apps that have an issue but all the webapps around the
world using jquery's ajax 1.9 stuff.
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.
Could you open a new thread/jiras for the doc issues so that we don't mix
all the things in one thread ?
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
>> 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 mailing list