----- Original Message ----- > From: "Lucas Holmquist" <lholmqui(a)redhat.com&gt; > To: "forge-dev List" <forge-dev(a)lists.jboss.org&gt; > Cc: aerogear-dev(a)lists.jboss.org > Sent: Tuesday, December 17, 2013 6:59:10 PM > Subject: Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD > > > On Dec 17, 2013, at 4:25 AM, Sebastien Blanc < sblanc(a)redhat.com > wrote: > > > > > Adding again aerogear list. > I think that we must discuss with the team (aerogear) on how we can/must > handle a proper 201 response. > > i don't see this as a client issue at all. jQuery ajax is used under the hood > here and it is handling the 201 fine, but it is choking on parsing the > response since it is not in the correct format, thus calling back in the > error callback. Ah, you mean this problem: http://jquery.com/upgrade-guide/1.9/#jquery-ajax-returning-a-json-result-... This would definitely require the server to not send empty responses when the client expects JSON.

> > this should really be handled on the server > > > > > > On 12/17/2013 09:58 AM, Ivan St. Ivanov wrote: > > > > Hi! > > I think that the 'right' approach is to respond with 201 (created) and return > a URI to the newly created resource. > > Cheers, > Ivan > > > On Tue, Dec 17, 2013 at 12:58 AM, Lincoln Baxter, III < > lincolnbaxter(a)gmail.com > wrote: > > > > Either is typical, but I think that most "pure" restifarians would favor the > 201. > > > On Mon, Dec 16, 2013 at 5:41 PM, Burr Sutter < bsutter(a)redhat.com > wrote: > > > > I need to find my REST bible - what is typical to respond to the POST with > the JSON-serialized entity that was originally POST'd or to simply respond > with a basic acknowledgement (http 201)? > > > On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira < vpereira(a)redhat.com > > wrote: > > > > > Adding forge-dev. > > ----- Original Message ----- > > > From: "Burr Sutter" < bsutter(a)redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > > Sent: Tuesday, December 17, 2013 1:59:41 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > That seems to do the trick - now, where do we apply the fix? :-) > > Well, ideally this would be a feature request in Forge to support a new type > of a REST resource. But a couple of modified lines might not warrant it. > > 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. > > It would most likely be addressed in Forge 2. > > > > > On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < vpereira(a)redhat.com > > wrote: > > > > > > > ----- Original Message ----- > > > From: "Lucas Holmquist" < lholmqui(a)redhat.com > > To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > > Cc: "Vineet Reynolds Pereira" < vpereira(a)redhat.com > > Sent: Tuesday, December 17, 2013 12:53:25 AM > Subject: Re: [aerogear-dev] Aerogear.js for CRUD > > > On Dec 16, 2013, at 1:52 PM, Burr Sutter < bsutter(a)redhat.com > wrote: > > > > Adding Vineet as he has spent time on the Forge REST scaffolding. > > On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < scm.blanc(a)gmail.com > wrote: > > > > Burr, > I've added some logs statements on the client and basically it seems it > can not parse the response from the server : > > I/Web Console( 1386): textStatus: parsererror at > file:///android_asset/www/js/index.js:103 > I/Web Console( 1386): error: SyntaxError: Unexpected end of input at > file:///android_asset/www/js/index.js:104 > > If I do a CURL like this : > curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > "Content-type: application/json" -X POST -d > '{"phoneNumber":"1234567890","email":" newTest(a)test.com ","name":"newTest"}' > http://agmobile-html5.rhcloud.com/rest/forge/members > > I should have pointed to the sources to the REST endpoint: > https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burr... > This was generated by Forge as I am too lazy to type up a full CRUD REST > endpoint myself :-) > > > > I got an correct answer but the content type is 'text/plain' , please > check your rest endpoint to be sure it's producing json as output, that > should solve your issue. > It says > @POST > @Consumes("application/json") > > needs a @Produces("application/json") > > I'm not sure that will help. The response is a HTTP 201 with a Location > header. > Is the client expecting an entity of type application/json in the response ? > > If yes, then the method should look like: > > @POST > @Consumes("application/json") > public Response create(MemberDTO dto) > { > Member entity = dto.fromDTO(null, em); > em.persist(entity); > return > Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build(); > } > > I've added : .entity(entity) in the above method to populate the response > with the entity. > > > > > > > > > > > Could you also paste the commands you used in Forge to scaffold the REST > endpoints so that we can check there hasn't been an incompatibility > introduced ? > I just used the Forge Wizard that is built into JBDS/Tools > http://screencast.com/t/QrKkCoFZMUn > > error.status is 201 > error.responseText is blank > > > > > > > > On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter < bsutter(a)redhat.com > wrote: > I am having a problem with pipe.save(), likely user error :-) > > For some reason, the POST is occurring, the save seems to work but the > error callback is invoked, not the success method. > > And I am doing all of this in the context of our tooling which has some > limitations (auto-closing console/firebug lite) > > http://screencast.com/t/gosd7Qnhz > > REST endpoint: > http://agmobile-html5.rhcloud.com/rest/forge/members > Use of Forge, with the Member.java entity to offer full CRUD capabilities > > Sources: > https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > 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." > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev