There has been a post or two regarding Seam and RESTeasy in the Seam forums, and the RESTeasy mailing list so I thought I would share my opinion as to where these technologies could fit together. I have been thinking about this since talking with Bill Burke at his JUG talk on RESTeasy.
For those who are not familiar RESTeasy it is an implementation of the JAX-RS specification that Bill Burke is working on. See RESTeasy project page for more info.
Some people get hung up on how these two technologies can integrate because Seam is by nature and definition a stateful framework, and REST by definition should be stateless. The question is not do they integrate, but can they co-exist?
I see two primary ways for Seam and RESTeasy to work together :
- Multiple ways to access/manipulate the same server side component.
If I have a Seam component (EJB or POJO does not matter) and I want to have it accessible via a restful call. I should be able to put the correct annotations on it from the JAX-RS spec, and have RESTeasy manage restful access. This EJB/POJO would effectively be both a seam component, and a restful service.
- Seam using restful calls as a result of a user action, or to pull data
Take for example a Seam application that displays TV schedules for any zip code in the country, and lets users create a calender of what shows they want to watch. Seam internally could make restful calls to an existing service for all of the TV schedule information. When the user selects a show the seam application captures the information from the service, and processes and stores that information locally using EJBs, POJOs, or whatever.
I suppose providing an easy way for Seam to access a remote restful service as a seam component would be useful. It could treat it like a stateless session bean, or something like that. Users today need to write the plumbing to make the restful call, and manipulate the return. I'll have to think on that some more :-)
My $.02
Jay, I think you bring up an excellent point here. Most people assume that a REST call must be made directly from the client. That approach introduces a problem I have cited many times before (including in Seam in Action): . Stateful components are very important because they serve as a memory for the application. Of course, you don't have to use a Seam component for that, but you should be using something to cache the result.
The REST protocol is design to make it easy to access resources from another computer, not to give you free reign to ask it for the same resource 100 times in a row.
Hello,
I think there would still be some integration code to write, for example if I do a RESTful call to a Seam bean, I won't get anything injected, right? And injecting application-scoped or stateless components makes perfect sense here, at least to me :)
Adam
You bring up a good point, and one I was thinking about as well. This is certainly where this co-existence could get tricky ;)
My first thought was that you need to be careful what you make a restful service. REST implies a lot of design paradigms, and there will certainly be some components that this does not fit into well. Although even the components that do make sense as a restful service may still require some amount of injection and management.
A Seam component that is also a restful service would need some sort of lifecycle hook or request listener that can do this management, but it should be hidden for the developer. I did not mean to imply that there would be no code changes in the frameworks for this behavior, but primarily that the end user should not need to be aware of it.
Some other hiccups I can see related to this:
- Alton Brown, Good Eats
I'm particularly interested in seeing the fruits of such a co-existence.
I've only experimented with things at a very rudimentary level, nothing more than exposing stateless beans in one seam app via RESTeasy and consuming them from within the action of another seam app (the RESTeasy proxy client made this trivial). Simple stuff but for a resource-based back-end that style of data-centric interaction made sense.
However, the questions around component authentication and (meaningful) stateful interactions are looming around the corner. It'd be great if some headway could be made on this within either framework but at the same time, I'd like to avoid a bastardization of either Seam or RESTful design principles.
Hello,
We've used Seam and RESTeasy for some time now in our project, and we're very happy with the results.
We've documented the process of integrating the two technos here: http://www.lunatech-research.com/archives/2008/03/20/restful-web-sevices-resteasy-jax-rs
Let me know if you have any comment :)
This is a nice insight to the topic on hand... Great blog, thanks keep it upn