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



----- Original Message -----
From: "Lucas Holmquist" <lholmqui@redhat.com>
To: "forge-dev List" <forge-dev@lists.jboss.org>
Cc: aerogear-dev@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@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-of-an-empty-string

This would definitely require the server to not send empty responses when the client expects JSON.

So in this case, with jQuery 1.9+ what is the best way for the us to handle this.  Is this a chance in AeroGear.js to help handle this situation, or do we need to make sure the server impls reply with content, even with a 201?



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