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 much more than HTTP GET support that is “RESTful” about RESTFaces. RESTFaces touts itself as being a
RESTfaces for JavaServerâ„¢ Faces Technology make it possible to write bookmarkable pages using JavaServerâ„¢ Faces.
In a nut shell: RESTFaces allows you to invoke actions via HTTP GET as opposed to just POST actions. JBoss Seam has a similar feature and their docs describes it as a means of making RESTFul applications that can be bookmarked. To be fair, Seam does not claim to be a full-on REST framework. Now I am a huge fan of JBoss Seam, so I don’t mean to come off as pooh-poohing that effort. But I wonder, is just providing GET support enough enough to be considered RESTful? At a low level, probably yes. But there could be so much more.
This could all change as the specifications for JSF and Web Beans matures. JSR-311 is a thriving work in progress and JSR-314 is also still getting ramped up as well. As these spec mature, some nice integration points might be:
Support for URI templates.
JSR-311 is currently defining support for this, but if this were integrated into JSF URIs would not be just bookmarkable, but also human readable. For example, instead of:
You could have something a bit cleaner
Your entry ID is now a component of the URI, which makes it a lot easier on the eyes. If you ever have had to deal with marketing applications, you can appreciate the value of this.
Support for multiple representations via HTTP Content Negotiation
Again this is something that JSR-311 is defining, but if this is integrated into JSF, or Web Beans for that matter, it would allow a single URI to deliver different media types. Using the example above, the same URI:
Could deliver the content as a PDF, or an HTML format that is more suitable for a mobile device and the decision is made by the framework. The user would not have to execute a specific URL for each type:
Through content negotiation, the user just needs the URI and the application will take care of delivering the proper response. If you’re looking for an example of a present day implementation, look no further than Apache HTTPD. JBoss Seam already supports a number of ways to generate other media types such as PDF, charts and graphs, and other, so I think they’re in a great position to deliver this kind of functionality. On the plus side, at least these two frameworks do allow one to use HTTP GET which is a big help.