Hi Sean, > I think *Representation is problematic: headRepresentation()? > I understand your > concerns with get(Variant), getVariant(). A colleague of mine > pointed out that > conceptually, merely using post(), get(), etc., is like > encroaching on a global > name space. He suggested (and I'm comfortable with), > doPost(), doGet(), doHead(), > doDelete(), doPut(), and doOptions(). The 'do' has the effect > of taking > the names out of the global name space...conceptually.
I agree, but what do you think about the fact that we already have the handleGet, handlePost, handleHead or handleOptions right in the Resource class? Do you think that handleHead() should call a doHead() method? What would be the added value? In case of handleGet() we provide a default implementation based on the getVariants() and getRepresentation(Variant) methods in order to provide a default support for content negotiation. Same for handleHead() which in 99% of the case is just a GET with no entity sent back on the wire. The handleOptions() also has a default implementation which is based on the "alloww*" methods available that return true. If you don't want to use content negotiation, you could directly override the handleGet(), handleHead() methods. Doesn't it cover your needs? Best regards, Jerome
