I did a bit of fiddling with RESTEasy yesterday. Following the examples in the jboss source, I was able to resolve a URL via RESTEasy after about 30 min of pom and web.xml wrangling. Not too bad.
RESTEasy pulled the following jars into my testing webapp (I chose the gradebook, since I’m familiar with its structure):
javassist-3.6.0.GA.jar
jaxrs-api-1.0.0.GA.jar
jsr250-api-1.0.jar
resteasy-jaxrs-1.0.0.GA.jar
scannotation-1.0.2.jar
slf4j-api-1.5.2.jar
slf4j-simple-1.5.2.jar
Is that too heavy? Well, since two of these are part of the logging facade, two are java standards libraries, and one is the RESTEasy implementation itself, I’d say that’s not too bad.
Once I was able to resolve URLs to my annotated Java classes, I decided to try something real, like annotating the method on GradebookService that finds a student’s score for a particular assignment. Here’s where a pretty severe RESTEasy limitation hit me: the spring integration does not work with manually proxied beans. Or put another way, you can’t resolve the JAX-RS annotations on most services in Sakai.
This got me thinking… is annotating the service APIs really what we want to be doing? Is there any reason to think that a Java service API necessarily models the granularity needed for a REST-ful web service? Assuming that the granularity of local APIs will meet the needs of remote APIs has killed a lot of technologies in the past.
I think in the most common cases, RESTful APIs will be different than Java APIs. A grading widget, for instance, would most likely need to show a paged set of scores, either one student’s scores for a set of assignments or the scores for many students on one assignment, while the API might use a more fine- or course-grained call (possibly further relying on lazily loaded collections, etc).
I think we need two very different kinds of REST-ful web services:
* Services that performs CRUD operations on entities. These should follow the RoR URL microformat. JAX-RS isn’t really designed to handle these kinds of boilerplate operations against entities.
* Services that provide the server-side support for “tool views”. These services would return exactly what particular UIs demand, possibly including data from a variety of Java services, using URL schemes defined by the needs of the tool itself. As a bonus, these services wouldn’t need any manual proxies, so they would get around the problems in RESTEasy’s spring integration (if the tool developer wanted to use spring).
I haven’t tried RESTEasy with any other IOC containers yet (I’m testing in Sakai 2.5.x, afterall), but I’m sure we can figure out a way to inject back-end / data services into these front-end REST services.