Re: [aerogear-dev] [forge-dev] Aerogear.js for CRUD

----- Original Message ----- > From: "Sebastien Blanc" <sblanc(a)redhat.com&gt; > To: forge-dev(a)lists.jboss.org, aerogear-dev(a)lists.jboss.org > Sent: Tuesday, December 17, 2013 2:55:14 PM > Subject: Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD > > 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'd concur. Both of these are 'correct'. But it would be better to indicate if the client or consumers of the client should do anything more for 201 responses. Several clients (Backbone.js [1], AngularJS[2] etc.) expect that responses to POST contain the entity in the response. Consumers are expected to fetch the updated resource for a 201 with an empty body.

1: https://github.com/jashkenas/backbone/issues/1660 2: https://github.com/angular/angular.js/issues/2572 > > 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