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="..." ...>
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 and REST
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
public String getCustomer(@PathParam("customerId") int id)
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.