Hi Bruno, > I see. So I guess it would be fair to consider that the > Resource object is more or less the equivalent of a closure > representing the dispatch of a request to the resource.
I think you can describe it this way. In the MVC pattern, the Resource class is the Controller, where the backend database or persistent POJOs or backend system is the Model and where the Representations are the Views. > I think I found my mistake. In Resource.handleGet(), it's the > fact there > isn't any Variant that leads to a CLIENT_ERROR_NOT_FOUND response > status. However, I was using this in the constructor, > whether-or-not the > resource existed: > getVariants().add(new Variant(MediaType.TEXT_PLAIN)); > Therefore, I shouldn't add any variant before I've made sure the > resource exists. True, this is the current behavior. I've just added an "available" property to the Resource class in SVN trunk (future 1.1) that will facilitate the explicit support of this use case. This new "available" property is set to true by default, but if you change it to false in the constructor (or in the init() method), then the handleGet() method will immediately return a Status.CLIENT_ERROR_NOT_FOUND without even looking at the list of variants. [...] > Not really at the moment, that was just an example. As you can guess > from my questions, I'm still learning about the framework. I have a > REST-based model in mind for my application that I would have > implemented with servlets, by I thought I'd be good to > investigate restlets. > So far, so good, but I'm not sure I'll use the Resource part of the > framework. I'm indeed planning to make a lot of short > requests and I'm a > bit concerned about creating a new instance of a Resource for every > request in terms of performance. I guess using a Restlet > directly might be more efficient in some cases. If you don't need the higher level API and features provided by the Resource class (conditional methods, content negotiation, etc.) then it is a good choice to rely on the Restlet class directly. Otherwise, I would recommend relying on Resource. The cost of creating one object instance is extremely low compared to the benefits provided by a thread safe processing context, with a higher-level view of your resources. Best regards, Jerome
