REST and JSF ?

JavaServer Faces is a great framework to build rich web applications, as shown in the following screenshot:

As you see, the web application in this screenshot is more an APPLICATION, than web… A pretty rich user interfaces, which was composed straightforward by using JSF strength, its declarative (markup-free) view:

<af:document title="..." ...>
  <af:tree />

REST – the web architecture…

The term REST was defined by Roy Fielding and it describes an architecture for web apps which use standard HTTP methods like GET, POST, PUT and DELETE to request and manipulate data. REST is (for me) a key component in WOA (web oriented architecture). A simple table to explain the mapping of the HTTP methods to the data manipulation:

HTTP GET -> /api/messages == get a list of messages
HTTP POST -> /api/messages == create a new message
HTTP PUT -> /api/messages/1 == modify message #1

As you can see the URLs in a RESTful (web) application are easy to bookmark…


JSF is a UI-centric web framework and REST is more available on the (web)service layer. Sure, on a HTTP GET /something you also get some result (HTML, JSON etc)… The RESTful URIs somewhat map directly to the data in the backend (e.g. the message #1). JSF is more about UI, meaning to present different datasources, via its components. In JSF you mostly use the POST HTTP method, when clicking on a link/button to create, update, delete or query some data. The HTTP POST (for a link/button command) can also mean that you may navigate to a different web page… So, this basically means the POST in JSF has definitely a different meaning than in REST…

One of the facts that some complain about in JSF is that the URLs aren’t bookmarkable. Usually JSF-based web apps are more application than web, as said before (ever tried to do a bookmark in a Word document on page 7?). However there are some ways, to workaround the bookmark issue in JSF (like using Servlet-Filters for pretty URLs)…

Bookmarks != REST

The bookmark factor I am not discussing here. If one would like to use REST-style for providing APIs for the applications, he is not only interested in bookmarkable URLs. Adding REST means that your front-controller supports PUT, DELETE and POST (to create things) on the service layer. Every HTTP client (like a browser or the curl tool) could use this API to deal with your application…

How to combine REST with JSF?

Good question. I am not really sure. The JSF 2.0 website says the EG eventually plans to support REST via the JSR 311 effort, but the latest draft of the specification doesn’t contain any hint regarding REST. So, how to integrate the REST-style with JSF? One possibility could be to integrate an adapter to support REST. This adapter would understand POST, GET, PUT and DELETE in a REST-way (and therefore different from the POST/GET in JSF). This adapter could be done with a different Servlet/Filter, that doesn’t map to the FacesServlet at all. The JSF lifecycle is also not needed to do REST, since this is more a service layer, than an actually GUI layer… The adapter could have access to other bits of the JSF framework, like the managed bean facility or the Unified Expression Language, and the adapter could (or should) be based on JSR-311.

I took a quick look at Ruby on Rails and they map the REST/HTTP methods to special methods in their controller (like show, destroy or create). Something like this could be done with a JSF ViewController (like available in Orchestra or Shale). Also Struts2 uses a similar approach to integrate REST. The JBoss Seam Framework already supports 311-based REST today. What they do is basically allowing the JBoss JSR-311 implementation to communicate with Seams DI mechanism:

public class MyCustomerResource
  CustomerDAO customerDAO;
  public String getCustomer(@PathParam("customerId") int id)
    return customerDAO.find(id).getName();

In the above sample the @Name and @In are Seam Annotations; the other ones are defined by JSR-311.

At the end this means there is no really close integration for supporting “real” REST. An extra adapter, like used in Struts2, Seam or Rails makes sense. That would also mean that there is no need to re-write the declarative JSF-view to treat the REST scenario as a special case (in those views). The REST integration actually happens on a different layer, but with an adapter as briefly discussed here, there would be still an integration to some core concepts of JSF, like its managed bean facility.



Posted in jsf, rest, web²
4 comments on “REST and JSF ?
  1. Very interesting idea. Given JSF’s nature of being a stateful web framework, REST would likely fit in very nicely and I think it could be done without interfering with the new asyncronous features of 2.0. Hmmm….

  2. Hey, just read your article and I completely agree. Take a look at this opensource package we released a short while ago to address these issues with JSF and bookmarkability, and let us know what you think. Thanks!

    It’s called PrettyFaces:

  3. […] Wessendorf)/@mwessendorf: bookmarkable URLS! = REST. Real rest is (very) hard w/ JSF Old, but good post on this […]

  4. Stefan Lecho says:

    Just wondering if there have been evolutions between 2008 and 2012 which allow to integrate JSF and REST in a more straightforward way ;o)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: