On 7/26/07, Adam Taft <[EMAIL PROTECTED]> wrote: > You're asking what's the best practice to use when coding your Resource.
Exactly! This approach allows the library to do the automatic content negotiation > and call getRepresentation(Variant v) with the appropriate Variant. If > you short circuit this and add in your Representation during > construction, basically you miss out on the ability to "switch" on the > Variant coming into the getRepresentation method. I'm assuming this statement is mostly true if the representations are expensive to construct? If I create three representations in the constructor, from what I can see, the Resource class will still conduct content negotiation. Finally, WRT efficiency... If you are running into bottlenecks or > slowdowns in creating the Resource classes (since they are created for > each request), perhaps you could do a couple of things: a) create a > Resource pool; b) use a Filter (or other Restlet type) to intercept > DELETE requests and not allow the request to create a Resource. Simply > intercept the delete request, perform the deletion, and block the call > back through to the Resource creator (ie. the default Finder class). Not so far; actually, the Restlet solution is heavily outperforming Rails, our other candidate for REST services. Rails services are a little easier to code, and experienced Rails devs make all sorts of productivity claims that I don't feel as if I can confirm or deny, but Restlet (and Java) are certainly markedly faster in our initial tests. That isn't to say that we wouldn't eventually need to look into scaling and profiling, just that, right now, performance doesn't seem to be a problem. With restlet over Hibernate, i've been able to see as much as 680 requests/second on a dev Core 2 Duo workstation. Actually, it feels at times as if the Restlet model is a little closer to REST in a few places (content negotiation where Rails seems to use the URL extension to determine representation format). Still, they're both pretty decent approaches, for the most part. Anyway, I would opt for #4 first. If you suffer performance penalties > (I don't know if you would), then you could optimize at that point. Sounds good, thanks! - Geoffrey -- Geoffrey Wiseman
