During Javaone 2010 I was able to meet Paul Sandoz, take a deeper look into Jersey’s code, attend to a session on ideas for the the JAX-RS comittee have for the future and show some of our ideas from Vraptor 3 (server side) and Restfulie (client side).
I wish JAX-RS 2 become the easiest and fastest way to develop resource and request based web applications on the Java platform, supporting all languages running on top of the JVM.
Based on that and what the VRaptor community has built in the past 7 years, this post goes through a few VRaptor points and decisions that I believe could make into a JAX-RS 2.0 spec.
In such scenario, we could make VRaptor support Jersey’s 1.x features thus become a new default implementation. A wild wish, that I intend to show why in the following examples:
VRaptor ideas
VRaptor is based on Convention over Configuration (CoC) and Do not Repeat Yourself (DRY). Lets start with a simple resource, removing all syntax noise that is possible from JAX-RS 1 favoring CoC. This is the basic VRaptor example:
It supports GET by default and will read the id query parameter. No annotations, no configurations. One can configure it the URI easily by doing:
After talking with Paul, I believe one could implement support to that id variable name thorugh Java SE features only – as Paranamer does internally.
Template engines (jsp, freemarker, velocity and others)
While still supporting content negotiation, VRaptor will default to rendering an html page in this case, making the software object instance available for the jsp file. Everything is easy to configure (i.e. jsp pattern, use freemarker and so on), of course. Your jsp file might look like:
URI Building
URI Builder in JAX-RS 1 is easy to use, but provides an extra coupling point to
all URIs. You will find yourself rewriting your URI patterns all over your code whenever one place references another one.
In JAX-RS you can design your code to wrap URI Builder in your project and only duplicate URIs once. But still there is one duplication, it is not refactor friendly and it is up to the developer to remember using this pattern.
Back in january 2009, Vraptor adopted a proxy approach that is refactor friendly and type safe, two important characteristics from the Java language that we do not have when using the URIBuilder approach (string based):
Because VRaptor uses a customizable Response builder interface, one can easily create generic responses that can be easily shared between projects or contributed to the project.
Injection
Any declared component is automatically wired in your resources, by using several different DI containers as Spring (default), Pico Container, Guice (and therefore CDI):
There is no need to define the interface but it makes your VRaptor Resources much easier to test once those components can be easily mocked or stubbed.
Validation
One of several programmatic approaches for bean validation is refactor friendly and makes use of Hamcrest:
In one line of code, you can also make use of the JSR for bean validation, of course.
Interceptors
You can create your own interceptors for any kind of custom behavior and VRaptor has its own stack by default. It’s embarassingly easy to create your interceptor:
File upload and download
An example of custom interceptor usage, one that already comes with VRaptor, is to enable easy to support download and upload. Both are one line of code away from your fingertips:
Again, in memory upload, maximum upload size and so on are easy to customize options in those interceptors.
Hypermedia and resources
Hypermedia is easily supported by implementing a HypermediaResource. Headers are supported either in the media type or the Link header:
Again, the code is refactor friendly and testable. VRaptor 2 suffered from annotation hell where annotations where used to replace configuration, a lesson learned: programmatic configuration gives support to both annotations and any language running on top of the jvm.
Enhancing lists with links within the representation is a one liner programmatic experience too (thus testable):
Summing up
For those reasons I strongly believe VRaptor ideas and default implementation could influence the resource and request based Java spec in a unique way.
Thanks to all VRaptor contributors that made VRaptor 3 available early 2009 and built a stronger release over and over so far and Caelum which allowed me, Lucas and others to spend a lot of time in its internals, including its course.