Hi all, Thanks for the quality of the feed-back. I feel like I'm now grasping all aspects of the problem and can propose a solution:
1) Split the Resource class into an abstract Handler class and a Resource subclass 2) Handler only works at the lower API level and specifies only the handle*() and allow*() methods. The default behavior is very basic: - nothing is allowed - handleHead() redirects to handleGet() and this is clearly documented - handleOptions() use the updateAllowedMethods() to automatically update the Response based on the available allow*() methods and their return value. - handleDelete(), handleGet(), handlePost() and handlePut() set the status to SERVER_ERROR_INTERNAL 3) Handler has convenience methods getApplication(), getLogger(), the "context", "request" and "response" properties. It also has a new allowHead() method which is invoked by the Finder. 4) Resource offers a higher-level API that, as Tim said, is easier to use to map to domain objects, handles content negotiation, conditional methods. - handleGet() is implemented based on the "variants" property, the getPreferredVariant() and getRepresentation(Variant) methods - handlePost() is implemented by calling an acceptRepresentation(Representation) method to match the REST/HTTP 1.1 terminology and have less parallel names. - handlePut() is implemented by calling a storeRepresentation(Representation) method to match the REST/HTTP 1.1 terminology and have less parallel names. - handleDelete() is implemented by calling a deleteAll() or delete() or removeAll() or remove(). See REST terminology here: http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_2 See HTTP 1.1 methods terminology here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html 5) Also, in order to provide a equivalent of the Handler.allow*() methods, I propose to map them (for GET, POST, PUT and DELETE only): - Handler.allowGet() -> Resource.readable property - Handler.allowPost() -> Resource.modifiable property - Handler.allowPut() -> Resource.modifiable property - Handler.allowDelete() -> Resource.modifiable property That's it, Finder would also require a few minor changes to only know about the Handler class. This would be backward compatible. Feed-back welcome. Best regards, Jerome > -----Message d'origine----- > De : Michael Terrington [mailto:[EMAIL PROTECTED] > Envoyé : dimanche 14 octobre 2007 01:25 > À : [email protected] > Objet : Re: HEAD not well supported? > > Tim Peierls wrote: > > There's a false parallel here that I don't think should be > encouraged by > > providing parallel names. getRepresentation takes a Variant > argument, > > handleGet does not; post takes a Representation argument, > handlePost > > does not. If anything, I'd argue for names that were *less* > parallel, > > e.g., add instead of post, and remove instead of delete. > > +1 for less parallel names, especially if handle* is moved to Finder. > The only difficulty I see is coming up with a good name for > post. Add > to me corresponds to remove, so perhaps createResource? > > Regards, > Michael.
