RESTFaces

Ryan J. McDonough has written a post called "Not much is RESTful in RestFaces and JBoss Seam", which discusses the RESTfaces JSF extension. On RESTfaces he concludes:

"I just came across a quick article on The Server Side about a JSF framework called RESTFaces. My initial reaction was 'oh cool, a JSF framework that might adhere to RESTful principals.' Sadly, there isn’t very much that is “RESTful” about RESTFaces."

Unfortunately, I have to agree. REST is becoming something of a buzzword these days and I suspect RESTfaces might be suffering from that instead of focusing on what it actually does, which is provided a patch for JSF to allow CGI style links. Looking at the documentation, it says:

 " RESTfaces for JavaServer™ Faces Technology make it possible to write bookmarkable pages using JavaServer™ Faces."

And that's true, it does, You'd think JSF would just get fixed to align itself with web architecture fundamentals, but ok. The documentation describes how links are provided,

 "We want to jump to a page containing item details, when the user clicks on the item link. The resulting detail page should be bookmarkable. The best way to accomplish this is using HTTP parameters."

Parameters are not the best way to do this in general, though they might well be wrt JSF. The documentation goes on to say:

" Now let's see how it's possible to invoke the action with RestFaces."

The giveaway word is "action"; unfortunately that's not REST style, that's RPC. Here's how action is  marked up:

<rest:link value="item">

   <f:param name="itemId" value="#{item.id}" />

   <h:outputText value="#{item.name}" />

</rest:link>

which strikes me as quite cluttered; an "a" tag with href seems like a nicer option.

Looking through the rest of the documentation suggests that RESTfaces is dealing with incidental complexity introduced by JSF itself, as the majority of the examples are about managing internal wiring and mappings. RESTfaces as far as I can tell is an RPC technology. I've described the technique it's using to provide links as "CGI/RPC explicit" in the past. This is where you pass the id of the resource you care about as a query parameter to a script, instead of addressing the resource directly. In OO terms that's just like hiding all your domain objects behind manager classes and passing primary keys around - something that would be unacceptable for modern Java development.

I suspect RESTfaces does what it can to patch around JSF's limitations to provide bookmarks, but part of me wonders, why bother? JSF is clearly not focused on or suitable for working in the REST style to the extent REST principles seem to be actively excluded from the design. So, in the context of the way JSF does things, it's fine to add CGI style extensions for something as fundamental as linking, but then the REST moniker isn't appropriate. I understand I'm being hard on RESTfaces here; in fairness frameworks not being aligned with the Web is the norm and I'm reminded about what Mark Nottingham said about web frameworks:

"URIs are the lynchpin of the Web; to get the full value of the Web infrastructure, you need to be able to identify every interesting part of your Web application with a URI. Unfortunately, common Web APIs don’t encourage this, or even actively discourage it."

Struts2 REST

On a more positive note, Stefan Tilkov links to some material about REST support in Struts2; it looks like someone did some digging into the Web's design. Check it out.

SpringMVC + Restlet

Personally, I think unifying SpringMVC, RESTlet routers and JSR311 annotations would give you most of what you need.

If you've used Django or Rails, then SpringMVC has a controller/view request model that will be intuitive, while being familiar enough to the legions that grew up on Struts ActionController. According to Jurgen Hoeller's post, "Annotated Web MVC controllers in Spring 2.5", Spring 2.5 introduces some web annotations:

"So how does Spring 2.5's annotation-based controller approach fit into this picture? Quite simple: It is essentially an alternative controller type supported by the DispatcherServlet / DispatcherPortlet, not implementing a specific interface but rather using annotations to express request mappings for specific handler methods. It is primarily a next-generation style for implementing multi-action controllers, superseding Spring's good old MultiActionController class"

I think once you go down the road of using annotations such as @Controller and @RequestMapping for HTTP, you'll end up looking at JSR311 annotations.

Beyond JSR311, the best URI mapping I've seen in the Java space is  RESTlet's Router API. Here's an example:

Router router = new Router(getContext());

router.attach("/users/{user}", UserResource.class);

router.attach("/users/{user}/orders", OrdersResource.class);

router.attach("/users/{user}/orders/{order}", OrderResource.class);

which is quite a bit more flexible than the default mappers shipped with SpringMVC. As an aside Guice Binders vaguely remind me of Restlet Routers. I'm guess I'm saying that your Java interfaces are merely Resource implementations ;)