On 7/26/07, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote: [...] > 4 - Do The Work Later > Do very little in the constructor; toss in a variant in the hopes the resource > exists.
I.e., add all of the "standard" types that we support across the entire application (i.e., in an abstract base class). > If it's a GET, I work in getRepresentation(Variant) to check if the resource > exists. If it does, I return a null variant and set the status code. > > If it's a DELETE, I issue a SQL delete that may or may not remove a record and > do nothing else. > > This approach does the least work, so is probably the best from a performance > perspective, but it again feels like I'm working a little cross-purposes in > the API by bypassing all that "If there's no variant, then 404" code in > Resource. Yes, I think this is the cleanest approach currently. > Actually, I'd be happy with this if Resource.handleGet() treated a null from > getRepresentation as a 404, but that might not work for all cases? Yes, I've been bitten by forgetting to set the status in the case of returning null from getRepresentation(). I'd suggest updating the JavaDocs to make this clear (either way) and to update example Part's 12 to show this clearly (either way) (e.g., log the issue, set the status, return null). Take care, John
