dev@jsr311.java.net

RE: Precondition support

From: Jerome Louvel <jerome.louvel_at_noelios.com>
Date: Tue, 10 Apr 2007 16:18:11 +0200

Paul,

> Were you also proposing the status should be obtained via a
> method as well?

Yes, but the status is related to the Resource POJO, not to the
Representation POJO. Order of calls could matter for resources as they have
life cycles.

> > Our
> > experience with the Restlet API led us to make the Resource
> class stateful.
> > Stateful in the sense that the instances are not shared
> between calls (they
> > may eventually be pooled). This is different from the rest
> of our upstream
> > handlers which are generally stateless (all the changing
> state is local to
> > the executing thread).
> >
>
> IIRC Marc and I referred to that in previous emails as being
> per-request
> life-cycle.

Ok, let's reuse your terminology. To me "per-request" makes sense as our
main resource life-cycle.
 
> Right. This is a key decision the EG needs to make as it impacts the
> design of other things.
>
> One very useful thing you can do with per-application life-cycle
> (singleton or like servlet) is the caching resource
> instances, and hence
> state.

Reusing resource instances across requests might be interesting from an
optimization point of view but I'm not sure if the drawback in term of
design simplicity of Resources is worth it.

In the Restlet API we considered this extensively and finally decided that
the performance gain (literally one instantiation as the supporting domain
objects can be cached/reused) wasn't worth the pain.

But, people are always free to implement resource pools/synchronized
singletons or just rely on a normal Restlets (or Servlets to maintain the
comparison).

> This is used to great effect by Hudson [1], a RESTful
> extensible
> continuous integration Web application. We have used Hudson as a real
> world use-case.

Nice use case indeed.

> We designed the API such that you define an object model of
> relationships between resources based on the URI hierarchy. It is
> possible for the application to choose whether to use
> per-application or
> per-request when moving through the object model as described
> by the URI
> path, which is consumed based on the URI templates. The closest
> documentation i have to explain this is what Hudson uses,
> called stapler
> [2].
>
> It creates a very flexible but intuitive way of building an
> extensible
> web application, for example see the section on stapler
> polymorphism [3].
>
> To get this more clearly across i think a demo would be best.

Sure, it that can bring some light on this design point. Concerning the
Restlet, I can point to an example showing the integration between Restlet
Resources and domaing objects (a simple bookmark management application):
http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet.ex
ample/src/org/restlet/example/book/rest/ch7/UserResource.java?rev=1727&view=
markup

Best regards,
Jerome