On Dec 17, 2013, at 4:36 AM, Vineet Reynolds Pereira <vpereira@redhat.com> wrote:



----- Original Message -----
From: "Sebastien Blanc" <sblanc@redhat.com>
To: forge-dev@lists.jboss.org, aerogear-dev@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.
These statements seem almost contradict each other.
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.  
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.

My definitions (which may be different than yours)
- 201 is the http response header/status
- 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)
- response body is where the JSON-serialized entity payload would be


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@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@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@redhat.com >
wrote:




Adding forge-dev.

----- Original Message -----


From: "Burr Sutter" < bsutter@redhat.com >
To: "AeroGear Developer Mailing List" < aerogear-dev@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@redhat.com >
wrote:






----- Original Message -----


From: "Lucas Holmquist" < lholmqui@redhat.com >
To: "AeroGear Developer Mailing List" < aerogear-dev@lists.jboss.org >
Cc: "Vineet Reynolds Pereira" < vpereira@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@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev


_______________________________________________
forge-dev mailing list
forge-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev



_______________________________________________
forge-dev mailing list forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev


_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev