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:
http://somehost/blog/entry.action?id=1234
You could have something a bit cleaner
http://somehost/blog/entries/1234
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:
http://somehost/blog/entries/1234
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:
http://somehost/blog/entries/1234.html
http://somehost/blog/entries/1234.pdf
http://somehost/blog/entries/1234.wml
Or worse:
http://somehost/blog/entry.action?id=1234&type=application/pdf
http://somehost/blog/entry.action?id=1234&type=text/html
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.
Damnhandy 
The RESTfaces framework has helped me overcome some major obstacles with the application that I wrote. Don’t be so hard on it. It covers the main functionality of sending a request to a JSF application from a bookmarkable page.
JBoss is just pure crap. I tried to install it and had many, many problems. That was even before I tried to even install Seam which is worse. STAY AWAY!!
LikeLike
The RESTfaces framework has helped me overcome some major obstacles with the application that I wrote. Don’t be so hard on it. It covers the main functionality of sending a request to a JSF application from a bookmarkable page.
JBoss is just pure crap. I tried to install it and had many, many problems. That was even before I tried to even install Seam which is worse. STAY AWAY!!
LikeLike
Hi, I am a RestFaces developer.
I admit my mistake (initially I called it ActionFaces then someone suggested me restfaces).
Anyway the TheServerSide post doesn’t speak about REST applications, but ok the name and some old part of documentation briefly report that misused word.
mAnyway thanks to your post I’ll try to bring a support for URI templates in RestFaces.
I have to think about Content negotiation instead…I don’t think it can be RestFaces feature..
Alberto Gori.
LikeLike
Hi, I am a RestFaces developer.
I admit my mistake (initially I called it ActionFaces then someone suggested me restfaces).
Anyway the TheServerSide post doesn’t speak about REST applications, but ok the name and some old part of documentation briefly report that misused word.
mAnyway thanks to your post I’ll try to bring a support for URI templates in RestFaces.
I have to think about Content negotiation instead…I don’t think it can be RestFaces feature..
Alberto Gori.
LikeLike
Gavin,
You’re right about the fact that Seam absolutely does not claim to be a RESTfui framework. I have updated the post to make that more clear.
Ryan-
LikeLike
Gavin,
You’re right about the fact that Seam absolutely does not claim to be a RESTfui framework. I have updated the post to make that more clear.
Ryan-
LikeLike
Oh, and P.S. I know what REST is, it’s you who have not done your research.
LikeLike
Oh, and P.S. I know what REST is, it’s you who have not done your research.
LikeLike
Actually URI patterns are quite trivial to support using something like UrlRewriteFilter. You can see an example of this in Seam Wiki, for example on in.relation.to. (Personally, I don’t quite see how “human-friendly” URLs has anything to do with the principles of REST, but let’s just let that one by, since I certainly can’t be bothered arguing the point.)
Content negotiation is something that I would like to see built-in to Seam, (there is an existing feature request for that in JIRA), but this is another thing that is *very* easy to implement in your application, JSF doesn’t get in your way at all here.
AFAIK, the case of DELETE is similar. ie. there is no built-in support, but there is also nothing that gets in your way of assigning a special semantic when the method on a non-faces request is DELETE instead of GET.
But, what I really want to point out is that Seam definitely does *not* claim to be a REST framework, or to “support REST”, or “to create RESTful applicationsâ€, or anything like that. The only claim we make on our website is the following:
“Seam even adds facilities for handling bookmarkable (REST-style) web pages – the number one user complaint against JSF.”
So please don’t tar Seam with the same brush as other products. I encourage you to search our documentation and web site, you won’t find anything inaccurate there. The link you provided is to a discussion of an *example* application, which is indeed RESTful, not to any claims that in general “Seam … makes RESTful applications”. So please post a correction. Thanks in advance.
LikeLike
Actually URI patterns are quite trivial to support using something like UrlRewriteFilter. You can see an example of this in Seam Wiki, for example on in.relation.to. (Personally, I don’t quite see how “human-friendly” URLs has anything to do with the principles of REST, but let’s just let that one by, since I certainly can’t be bothered arguing the point.)
Content negotiation is something that I would like to see built-in to Seam, (there is an existing feature request for that in JIRA), but this is another thing that is *very* easy to implement in your application, JSF doesn’t get in your way at all here.
AFAIK, the case of DELETE is similar. ie. there is no built-in support, but there is also nothing that gets in your way of assigning a special semantic when the method on a non-faces request is DELETE instead of GET.
But, what I really want to point out is that Seam definitely does *not* claim to be a REST framework, or to “support REST”, or “to create RESTful applicationsâ€, or anything like that. The only claim we make on our website is the following:
“Seam even adds facilities for handling bookmarkable (REST-style) web pages – the number one user complaint against JSF.”
So please don’t tar Seam with the same brush as other products. I encourage you to search our documentation and web site, you won’t find anything inaccurate there. The link you provided is to a discussion of an *example* application, which is indeed RESTful, not to any claims that in general “Seam … makes RESTful applications”. So please post a correction. Thanks in advance.
LikeLike
“RESTful” seems to mean whatever the fanatic of the day says it means (i.e. do it my way you unRESTful sinner, or else). The magical qualities of the wonderful internet in its perfect state with everyone GETting and PUTting and POSTing and DELETE-ing never seems quite clear in substance, but *sigh*, I guess since the web has been such a huge story of failure without half (yes, half) of those commands, that we really need to get RESTful in order to fix it.
BTW, URI templates work great on just about any system with a simple rewriter module, which is what the Seam peeps suggest. Either way, its all just zealotry anyway.
LikeLike
“RESTful” seems to mean whatever the fanatic of the day says it means (i.e. do it my way you unRESTful sinner, or else). The magical qualities of the wonderful internet in its perfect state with everyone GETting and PUTting and POSTing and DELETE-ing never seems quite clear in substance, but *sigh*, I guess since the web has been such a huge story of failure without half (yes, half) of those commands, that we really need to get RESTful in order to fix it.
BTW, URI templates work great on just about any system with a simple rewriter module, which is what the Seam peeps suggest. Either way, its all just zealotry anyway.
LikeLike