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

Tue Dec 17 04:36:14 EST 2013

----- Original Message -----
> From: "Sebastien Blanc" <sblanc at redhat.com>
> To: forge-dev at lists.jboss.org, aerogear-dev at 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 at 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 at 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 at redhat.com >
> wrote:
> 
> 
> 
> 
> Adding forge-dev.
> 
> ----- Original Message -----
> 
> 
> From: "Burr Sutter" < bsutter at redhat.com >
> To: "AeroGear Developer Mailing List" < aerogear-dev at 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 at redhat.com >
> wrote:
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> 
> 
> From: "Lucas Holmquist" < lholmqui at redhat.com >
> To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org >
> Cc: "Vineet Reynolds Pereira" < vpereira at 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 at 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 at 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 at 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/burrsutter/agmobile/rest/MemberEndpoint.java
> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> 
> 
> _______________________________________________
> forge-dev mailing list forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev