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