<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 17, 2013, at 4:36 AM, Vineet Reynolds Pereira <<a href="mailto:vpereira@redhat.com">vpereira@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><br>----- Original Message -----<br><blockquote type="cite">From: "Sebastien Blanc" <<a href="mailto:sblanc@redhat.com">sblanc@redhat.com</a>><br>To:<span class="Apple-converted-space"> </span><a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>,<span class="Apple-converted-space"> </span><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>Sent: Tuesday, December 17, 2013 2:55:14 PM<br>Subject: Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD<br><br>Adding again aerogear list.<br>I think that we must discuss with the team (aerogear) on how we can/must<br>handle a proper 201 response.<br></blockquote><br>I'd concur. Both of these are 'correct'. But it would be better to indicate<span class="Apple-converted-space"> </span><br>if the client or consumers of the client should do anything more for 201 responses.<br><br>Several clients (Backbone.js [1], AngularJS[2] etc.) expect that responses to POST contain<br>the entity in the response. Consumers are expected to fetch the updated resource for a 201<br>with an empty body.<br></div></blockquote>These statements seem almost contradict each other.</div><div>If Backbone/Angular assume that the response to a POST is a 201 with the entire entity from the server then that suggests that Aerogear's default is also correct behavior, in which case, the Forge scaffolding should be corrected. </div><div>If "Consumers are expected to fetch the updated resource for a 201with an empty body", then no JSON serialized entity is needed in the response.</div><div><br></div><div>My definitions (which may be different than yours)</div><div>- 201 is the http response header/status</div><div>- entity is the entire object (e.g. Person, Customer, Part, Order) that was originally POST'd/INSERTed + any default values returned by the ORM+RDBMS (e.g. auto-inc id, pre-populated fields from triggers, etc)</div><div>- response body is where the JSON-serialized entity payload would be</div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>1:<span class="Apple-converted-space"> </span><a href="https://github.com/jashkenas/backbone/issues/1660">https://github.com/jashkenas/backbone/issues/1660</a><br>2:<span class="Apple-converted-space"> </span><a href="https://github.com/angular/angular.js/issues/2572">https://github.com/angular/angular.js/issues/2572</a><br><br><br><blockquote type="cite"><br>On 12/17/2013 09:58 AM, Ivan St. Ivanov wrote:<br><br><br><br>Hi!<br><br>I think that the 'right' approach is to respond with 201 (created) and return<br>a URI to the newly created resource.<br><br>Cheers,<br>Ivan<br><br><br>On Tue, Dec 17, 2013 at 12:58 AM, Lincoln Baxter, III <<br><a href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a> > wrote:<br><br><br><br>Either is typical, but I think that most "pure" restifarians would favor the<br>201.<br><br><br>On Mon, Dec 16, 2013 at 5:41 PM, Burr Sutter < <a href="mailto:bsutter@redhat.com">bsutter@redhat.com</a> > wrote:<br><br><br><br>I need to find my REST bible - what is typical to respond to the POST with<br>the JSON-serialized entity that was originally POST'd or to simply respond<br>with a basic acknowledgement (http 201)?<br><br><br>On Dec 16, 2013, at 4:25 PM, Vineet Reynolds Pereira < <a href="mailto:vpereira@redhat.com">vpereira@redhat.com</a> ><br>wrote:<br><br><br><br><br>Adding forge-dev.<br><br>----- Original Message -----<br><br><br>From: "Burr Sutter" < <a href="mailto:bsutter@redhat.com">bsutter@redhat.com</a> ><br>To: "AeroGear Developer Mailing List" < <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> ><br>Sent: Tuesday, December 17, 2013 1:59:41 AM<br>Subject: Re: [aerogear-dev] Aerogear.js for CRUD<br><br>That seems to do the trick - now, where do we apply the fix? :-)<br><br>Well, ideally this would be a feature request in Forge to support a new type<br>of a REST resource. But a couple of modified lines might not warrant it.<br><br>It would be better to treat this as a flag to be enabled during REST resource<br>scaffolding. It would allow users to choose how the resource behaves -<br>* send a 201 response with Location header,<br>* send a 201 response with Location header and also a response entity.<br><br>It would most likely be addressed in Forge 2.<br><br><br><br><br>On Dec 16, 2013, at 3:06 PM, Vineet Reynolds Pereira < <a href="mailto:vpereira@redhat.com">vpereira@redhat.com</a> ><br>wrote:<br><br><br><br><br><br><br>----- Original Message -----<br><br><br>From: "Lucas Holmquist" < <a href="mailto:lholmqui@redhat.com">lholmqui@redhat.com</a> ><br>To: "AeroGear Developer Mailing List" < <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> ><br>Cc: "Vineet Reynolds Pereira" < <a href="mailto:vpereira@redhat.com">vpereira@redhat.com</a> ><br>Sent: Tuesday, December 17, 2013 12:53:25 AM<br>Subject: Re: [aerogear-dev] Aerogear.js for CRUD<br><br><br>On Dec 16, 2013, at 1:52 PM, Burr Sutter < <a href="mailto:bsutter@redhat.com">bsutter@redhat.com</a> > wrote:<br><br><br><br>Adding Vineet as he has spent time on the Forge REST scaffolding.<br><br>On Dec 16, 2013, at 7:01 AM, Sebastien Blanc < <a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a> > wrote:<br><br><br><br>Burr,<br>I've added some logs statements on the client and basically it seems it<br>can not parse the response from the server :<br><br>I/Web Console( 1386): textStatus: parsererror at<br><a href="file:///android_asset/www/js/index.js:103">file:///android_asset/www/js/index.js:103</a><br>I/Web Console( 1386): error: SyntaxError: Unexpected end of input at<br>file:///android_asset/www/js/index.js:104<br><br>If I do a CURL like this :<br>curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H<br>"Content-type: application/json" -X POST -d<br>'{"phoneNumber":"1234567890","email":" newTest@test.com ","name":"newTest"}'<br>http://agmobile-html5.rhcloud.com/rest/forge/members<br><br>I should have pointed to the sources to the REST endpoint:<br>https://github.com/burrsutter/agmobile/blob/master/src/main/java/com/burrsutter/agmobile/rest/MemberEndpoint.java<br>This was generated by Forge as I am too lazy to type up a full CRUD REST<br>endpoint myself :-)<br><br><br><br>I got an correct answer but the content type is 'text/plain' , please<br>check your rest endpoint to be sure it's producing json as output, that<br>should solve your issue.<br>It says<br>@POST<br>@Consumes("application/json")<br><br>needs a @Produces("application/json")<br><br>I'm not sure that will help. The response is a HTTP 201 with a Location<br>header.<br>Is the client expecting an entity of type application/json in the response ?<br><br>If yes, then the method should look like:<br><br>@POST<br>@Consumes("application/json")<br>public Response create(MemberDTO dto)<br>{<br>Member entity = dto.fromDTO(null, em);<br>em.persist(entity);<br>return<br>Response.created(UriBuilder.fromResource(MemberEndpoint.class).path(String.valueOf(entity.getId())).build()).entity(entity).build();<br>}<br><br>I've added : .entity(entity) in the above method to populate the response<br>with the entity.<br><br><br><br><br><br><br><br><br><br><br>Could you also paste the commands you used in Forge to scaffold the REST<br>endpoints so that we can check there hasn't been an incompatibility<br>introduced ?<br>I just used the Forge Wizard that is built into JBDS/Tools<br>http://screencast.com/t/QrKkCoFZMUn<br><br>error.status is 201<br>error.responseText is blank<br><br><br><br><br><br><br><br>On Sat, Dec 14, 2013 at 6:06 PM, Burr Sutter < bsutter@redhat.com > wrote:<br>I am having a problem with pipe.save(), likely user error :-)<br><br>For some reason, the POST is occurring, the save seems to work but the<br>error callback is invoked, not the success method.<br><br>And I am doing all of this in the context of our tooling which has some<br>limitations (auto-closing console/firebug lite)<br><br>http://screencast.com/t/gosd7Qnhz<br><br>REST endpoint:<br>http://agmobile-html5.rhcloud.com/rest/forge/members<br>Use of Forge, with the Member.java entity to offer full CRUD capabilities<br><br>Sources:<br>https://github.com/burrsutter/AGContacts/blob/master/www/js/index.js<br><br><br>_______________________________________________<br>aerogear-dev mailing list<br>aerogear-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br><br>_______________________________________________<br>aerogear-dev mailing list<br>aerogear-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br><br>_______________________________________________<br>aerogear-dev mailing list<br>aerogear-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br><br><br>_______________________________________________<br>aerogear-dev mailing list<br>aerogear-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br><br><br>_______________________________________________<br>aerogear-dev mailing list<br>aerogear-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br>_______________________________________________<br>forge-dev mailing list<br>forge-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/forge-dev<br><br><br>_______________________________________________<br>forge-dev mailing list<br>forge-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/forge-dev<br><br><br><br>--<br>Lincoln Baxter, III<br>http://ocpsoft.org<br>"Simpler is better."<br><br>_______________________________________________<br>forge-dev mailing list<br>forge-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/forge-dev<br><br><br><br>_______________________________________________<br>forge-dev mailing list forge-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/forge-dev<br><br><br>_______________________________________________<br>forge-dev mailing list<br>forge-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/forge-dev<br></blockquote>_______________________________________________<br>forge-dev mailing list<br><a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/forge-dev">https://lists.jboss.org/mailman/listinfo/forge-dev</a></div></blockquote></div><br></body></html>