Does Roo need some REST?

Hi all,

Spring provides two ways to transform a java domain object into the representation that will be shipped to the client:

1. Content Negotiating View Resolver.
a) "Accept" parameter in the header.
b) Based on the URL: http://some/foo/1.xml, http://some/foo/1.json.
2. HTTP Message Converters (as explained in Pro Spring 3 book).

Roo supports REST through "json" add-on so we can request an object with:

curl -i -H "Accept: application/json" http://localhost:8080/addressbook/contacts/1

But, there isn't any "rest xml" add-on ready to use (http-representation add-on is obsolete). So the following command won't work:

curl -i -H "Accept: application/xml" http://localhost:8080/addressbook/contacts/1

And even more. The way Roo supports json is by creating a new controller instead of taking advantage of the ContentNegotiatingViewResolver or HTTP Message Converters. Also Roo's command "web mvc all" makes the Controllers to return a String, the name of the view, instead of returning the object and delegating the view to a ViewResolver. Wouldn't the second approach be a better solution?

Does anyone know why? I don't mind to develop something for the community but first we need to know the direction. What would be the best approach?

Your thoughts?
Agustin

There is a content negotiating view resolver add-on. Did you try that one?

If you're looking for just view data translation and supporting different media formats, that may be the ticket. But if you are writing a wholly JSON/REST backend you can just use things like @RequestBody and @ResponseBody (or @RequestEntity/@ResponseEntity) in your controllers and install the Json plugin.

REST in Roo 1.2.3 can be as simple as (sorry, from memory so syntax will be meh):

1. Install the json add-on
2. Annotate your model/transfer objects with @RooJson
3. Write a controller

Code:

---

@RequestMapping("/courses")
@Controller
@RooWebScaffold(path = "courses", formBackingObject = Course.class)
public class CourseController {

  @RequestMapping("/courses", produces = "application/json")
  public@ResponseBody String getCourses() {
    return Courses.findAll().toJsonArray();
  }
}

---

So maybe you don't need to write an add-on if you have specific requirements. The Roo 1.2.3 release includes Spring 3.2 so that enables some enhanced functionality in Web MVC with REST.

Ken, thanks for your reply. Yeah, I think the "content negotiating view resolver" add-on you are talking about is the "http-representation" add-on developed by Tzolov. I tried it already but it doesn't work with XML out of the box. Suppose the following scenario: A simple web application with REST support. And by that I mean full support. CRUD functionality through web (browser), xml and json. With Roo you could do the following:

Code:

---

jpa setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY
entity jpa --class ~.domain.Event
field string --fieldName name
field string --fieldName description
field date --fieldName startdate
web mvc setup
web mvc all --package ~.web
json all
web mvc json all --package ~.web

---

That will give you CRUD functionality for the web and json formats. Now if you want to add xml, csv or other format you don't have any Roo command out of the box. The only options are:

1. Message Converters: You would have to push in all your controllers because "web mvc all" creates them returning a string (the name of the view) instead of the object. And also add ResponseBody/RequestBody annotations.
2. Content Negotiating View Resolver: You could use both jaxb-addon and http-representation add-ons. The first one adds jaxb annotations to your domain classes (it creates a different set of classes so you would need to merge both classes, the ones created by jaxb-addon with jaxb annotations and the ones created by Roo with jpa annotations). The http-representation add-on will add the view resolver by extension (http://server/some/foo.xml, http://server/some/foo.json) but it will work only for GET, not for POST, PUT and DELETE.
3. The third option is to do something similar to "json all" and "web mvc json all" commands. Create another set of methods in your controller to handle each format: xml, csv, …

It would be more convenient to decide the type of view resolver in the moment of creating the controllers, something like: "web mvc all --viewResolver (MESSAGE_CONVERTER | CONTENT_NEGOTIATING)" and that would give us CRUD functionality in several formats (html, xml, json, pdf, etc) out of the box.

Does it make sense or I am missing anything?

Thanks again :)