Restling with Restlet

We have been using restlet (Version 1.1.3) as the web framework on our current project and I thought It might be useful to share our experiences.

Initially we chose it because it seemed a good match to what we wanted to achieve. We wanted to write a pure http interface to our application. Restlet is all about routing http requests to “resources” it maintains the semantics of restful applications and so you have put, post, get, delete methods and resources and representations of these resources. All very restful and good.

It was pretty fast to get going. We knew we were going to use DI in our app and so wanted to configure restlet in that way. Sure enough, there is a spring front controller out of the box.

It also had out-of-the box support for Freemarker. Having used velocity extensively, we had heard good things about freemarker and this seemed a good enough choice as a templating library although we were originally keen to use string template (but that’s another post!).

So we were up and running quite quickly. However there were a few “features” which have made life less than rosy for us. I am going to just briefly list them here. To be fair some of these are due to the Spring integration, which could be avoided.

Inheritance based:

In order to be part of the framework, you have to extend the restlet class “Resource”. This results in several of the issues below.

Verbose spring configuration

Because restlet needs to intantiate new “resources” from spring, it needs to do some of its own injection with things like the response and request (due to the inheritance feature). So you can’t just declare your resource bean in the spring config, you have to wrap it in a class called “SpringFinder”. It ust means that your spring config looks a bit verbose and noisy.

Matching URI patterns:

Restlet has rather a complex URI pattern matcing algorithm. Im sure this has some use somewhere, but involves some kind of weighting strategy (well actually a choice of several). This in itself is not too bad, but to do the simplest thing is not the first configuration. It took a bit of digging about to find out that in order to just exactly match the URI you map in the config, you have to Override the method getMatchingStrategy and return a value.

A suggestion might be to have the routing algorithm encapsulated as a Strategy object. That way, it could come with a default strategy which is just exact matching, and then if you need the more complex algorithm it would be easy to swap in.

We first noticed this when we mapped a uri something like /contextroot/someentitylist/22 if you try /contextroot/someentitylist/22/foobar you dont get a 404, it just goes to your resource.

Complex api

Sometimes things seem a little tricky to do. For example, to get the Http headers from the request, you have to get a Form object which is a bit strange, its like it was re-used just because it sort of looked like a web form, instead of just having a specialised object to represent the headers. I guess that sometimes it seems a little too generic which means you need to do some interpretation of the object model to get what you want.

Noisy logging

We wanted to implement the Cache-Control and Pragma headers. It lets us do it but complains noisily in the log output, on the error stream telling us that we shouldnt do this, because It will be implemented in a future version!!. It logs this at SEVERE level!. This is rather patronising and now fills the log file with noise.

Inheritance based (again)

In order to inform the framework that you allow puts and posts, you have to override the methods allowPut() and allowPost()

All of which led us to create a single derivation of their class and then delegate to new classes of our own devising thus breaking the inheritance tree, or “running away from home”.

Thread Local Storage

While im not necessarily saying TLStorage is a bad thing per se, you do need to be careful in a web app that anything you put on it, you remove at the end of each request processing, because otherwise it just stays there and builds up in the vm. Felix and Martin were looking into some memory leak stuff in our web app and discovered this interesting fact. It was easily fixed by just setting the instances to null at end of request. Maybe we were using the framework incorrectly and so had not called the appropriate sequence, but even so, something so important should be impossible for us to get wrong. I think they used Your Kit for the job which they were pleased with as it pointed them directly at the classes in question.

General vibe

Basically, it feels most of the time that you are being made to jump through hoops to integrate with the framework. I feel that frameworks should be transparent and non-invasive.

What do you think ?

Do you have any experience with Restlet ? Maybe we are just not using it in the right way. I do notice that we are using the stable version so I haven’t looked at what is upcoming.

Share

4 thoughts on “Restling with Restlet

  1. > I feel that frameworks should be transparent and non-invasive

    You mean it should be a library? ;-)

    Anyway couldn’t you get away with delegation at your framework hot spots? Basically, do the simplest possible marshalling and call out to your own classes. Then you could keep your classes pure and only worry about Restlet for integration?

  2. Hi Lasse,

    Thanks for the comment.

    Yeah, In my previous post about frameworks , I thought I might be really talking about a library. Also Pat picked up on the distinction there too.

    r.e. Isolating our code from the framework, its a good point, indeed this is what we ended up doing, creating our own API and just using Restlet underneath. One down side to this is that there is more code in the application, so its another level of indirection to go through for anyone maintaining it.

  3. We re-evaluated our usage of the Mattress Framework (http://mattressframework.org/) recently, to see if we would rather move to Restlet. We concluded that Restlet was way too complex and too feature rich to fit the bill (after being used to the elegant simplicity of Mattress).

    So we postponed our migration until Spring 3.0 final is out, as we will most likely migrate to their REST support.

  4. Thanks David,

    It’s interesting that you found something similar. I will have a look at Mattress. Actually I have been thinking about writing my own framework so will be interested to see what’s in Mattress.

    It also links to JSR 311 – JAX-RS: The JavaTM API for RESTful Web Services.

Comments are closed.