Rails, JSR311, Restlet and Jersey

In an earlier post (https://thestewscope.wordpress.com/2007/12/21/rest-moving-to-java/) I had declared my intention to depart from using Ruby/Rails as a means of creating RESTful web-services fronting what I regard as a more complex set of resource implementations than Rails appears to be comfortable with.

Since that time I’ve been investigating JSR3-11 and 2 early implementations on the Java platform, Restlet and Jersey respectively. The creator of Restlet (Jerome Louvel) is a member of the JSR3-11 expert group working on the evolution of the spec and as such is well placed to oversee the development of his very tidy Restlet framework. Jersey on the other hand is the Sun reference implementation of the spec, and relies more on convention and pojo annotation in place of the more structured/prescriptive framework put together in Restlet framework.

My initial feelings were that moving up the food-chaing from Rails (I stress that when I say food-chain I am implying an order of relative capability within my specific problem-space and not disrespecting the Rails community at all) that Restlet would be the more natural home or stepping stone towards an Enterprise class framework – which is effectively where I am exploring the applicability of RESTian principles….as an alternative to Enterprise SOA WS*. However as I have begun to dig deeper into the real requirements of ‘my next framework’ I am beginning to favour Jersey as my next hop. But I’m currently unsure of the relative merits…


Well Restlet offers a neat and slick way for me to assemble components with certain roles into chains, behind URI patterns enabling a lightweight RESTful facade to be created quickly but with a little more enterprise-integration power under-the-hood than rails. However the current evolution of Restlet appears to be a little limited in the area of connector classes and the tools that help me do the real work of applying my RESTful uniform interface to my complex enterprise engine-room. As a result – I believe I’d be dropping back to engineering the guts of my integration code on an alternative platform such as Glassfish. For that reason – I’m starting to think the Jersey option may initially offer the same ability to create a resource facade but also be a natural point of extension when I need to bolt heavier back-end integrations into the RESTful presentation. As such I can’t help but feel that starting out with Jersey on Glassfish would be a foundation that I could grow, as opposed to taking a step forward with Restlet but then relying on Glassfish hosted components down the line…

 One thing is for certain in my mind right now. RESTful principles applied to the Enterprise need more than Rails – but I’m still unsure of the Restlet/Jersey route…but Jersey on Glassfish just feel like they may just withstand a little more heat in an Enteprise scenario…


2 Responses to Rails, JSR311, Restlet and Jersey

  1. You could also combine Restlet and JAX-RS, because JAX-RS gets an extension to support JAX-RS. Restlet 1.1 contains an experimental version of this extension.

  2. Stew Welbourne says:

    I moved through a couple of iterations on this and arrived at a vanilla SpringMVC application supporting a dynamic namespace through a single front-end controller. I am therefore able to data-drive my namespace without explicit wiring of resource names to code objects…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: