Roo not really RESTful?

[rvillars]

Hi there.

I lately tried to generate a RESTful backend with Roo by using the web mvc json mechanism.

json all
web mvc json setup
web mvc json all --package ~.controller

It seems to me, that the generated controllers don't really stick to the RESTful good practices.

For example an update request should be called with an URL like host/application/books/1 using HTTP PUT and giving the changed json object in the request.

Unfortunately the created update method looks like this:

@RequestMapping(method = RequestMethod.PUT, headers = "Accept=application/json")
public ResponseEntity<String> BookController.updateFromJson(@RequestBody String json)

This fits to a URL like host/applikation/books with HTTP PUT.

Even worse: The showJson method matches perfectly to the REST update request and isn't limited to HTTP GET. With that for every REST update request actually the showJson method is called instead of the updateFromJson method.

There are also other deviations like the missing resource links in the response of update and create methods.

All this makes using client side REST frameworks like AngularJS ngResource almost impossible.

I'm not sure if this is a bug in Roo's json-addon or it is so by purpose. Alternatively a rest-addon would be helpful that creates proper RESTful controllers.

[Wesker317]

See it like this : Roo generates a TEMPLATE for you. In my current project, even if roo originally generated all my controllers, in my production code there are no fully auto-generated controller method left. I used the roo generated controller/methods as templates for my real code.

So for your REST problem (which I had same as you juste last week), just push-in every method and quickly adapt them to your reality. So you can limit "showJson" to GET, and create a PUT method with a pathValue.

From reading most of the posts on this board, it seems to me like everyone thinks that Roo will do 100% of the work and that you can have a million dollar e-commerce transactionnal website in a few minutes without having to write any actual code...

[rvillars]

Hi Wesker317. Thx for your answer.

I totally agree with you. Spring Roo should be just a template.
But it is also the nature of a template to fit the most common needs of a defined domain.

If you look at REST capable frameworks like AngularJS, Play, Restlet, etc. you will see that they all share a more or less uniform "style" of how REST APIs are built. And it is different to what Roo generates at the moment.

For me this is completely OK if there is a good reason for that like "We do this to ensure compatibility to framework XY". Then I would probably just create a new add-on like "addon-rest".

But if it is just because "we didn't know it any better, it is just an how we thought it can be done", then it would be better to change the "template" to fit the needs of the domain. I will then create am issue for that in JIRA.

What do you think is the reason that the REST API Roo creates is different to others?

[Wesker317]

You are right that Roo should generate code that fits the most common or normal way of doing things.

I just did not want you or anyone reading this thinking that it's impossible to use Roo with Rest frameworks like the one you mentionned. Sure it' dosen't work exactly right out of the box, but the job's about 90% done. Sure beats having to do 100% of the work.

I'm always happy with Roo since I never expect it to do EVERYTHING for me and it succeeds in that regard.

[dav0]

In my humble opinion, this is a good catch. I would go ahead and enter a Jira around this - and please post a link to it's Jira number as a reply here for convenience of tracking this issue.

If it turns out that there is a reason not to correct this behavior in Roo, then the reason can be posted in the Jira and the issue closed. Otherwise, I would very much like to see this resolved ASAP, as there is a huge potential use case here.

Thanks!

[siegfried]

So can someone point me to a tutorial where this problem with the template is corrected so I can do it correctly?

Just how severe is this problem? Can I still use curl to demonstrate the REST API with the code generated by ROO?

Does this flaw in ROO limit the functionality of a REST client?
Is it a performance problem?
OK, I'm re-reading it now... So I cannot use AngularJS. So how hard is it to correct the problem by editing the ROO source code? Is that not the suggested solution?
Hmm.... Yes it looks like AngularJS is just what I was looking for...
Yes! Please tell me how to modify the template so I can use it with AngularJS...

Thanks
Siegfried

[dav0]

Hello again Siegfried,

Ordinarily we might hear a quick answer as to how to proceed with this issue from Alan Stewart, former tech lead of the Roo project, but it appears that destiny has currently dealt Alan a challenging hand (see http://forum.springsource.org/showth...o-project-lead ).

I feel like I have basically the same questions rolling around in my head. Judging from the "Getting Started page ( http://www.springsource.org/get-involved ), we may want to start by entering a Jira against this issue - this I can probably do - but as to how to proceed to fixing it, I am not yet sure either, but I too am willing to try and help if and where I can (assuming this really is a bug).

-dav0

[rvillars]

Hi. Thank's to all for your input. As I mentioned it's not just an issue with AngularJS. It's really a discrepancy to the HTTP specification.
If you don't mind I'm going to raise a JIRA ticket with a proper example of how the generated code is and how it should be IMHO. I will post the link here as soon as it's done.

[rvillars]

The JIRA issue is https://jira.springsource.org/browse/ROO-3376

[dav0]

The JIRA issue is https://jira.springsource.org/browse/ROO-3376

Thanks for posting that Roger - everyone should VOTE on this ROO/REST JIRA issue :

https://jira.springsource.org/browse/ROO-3376