Hi all, Thanks for sharing your experience. This is very valuable feed-back and I want to address these issues to this core class in release 1.1 if possible/necessary.
To try to clarify, I was initially hesitant to call getRepresentation(Variant) just get(Variant) due to potential confusion with the Javabeans naming, especially because we also need a way to get the variants available. Having both a get(Variant) and a getVariants() method seemed confusing to me. So, I dediced to keep the uniform methods in Resource via the handle*() methods (see Resource.handleHead(), handleOptions(), etc.) and to provide good default implementations. So, handleGet() does a getVariants() then a getRepresentation(Variant) on the best matching variant. handleHead() delegates to handleGet(), handlePost() calls post(Representation), etc. The current approach I'm following for 1.1 is to try to move those Resource.handle() methods to the Finder class and only keep the higher level methods in Resource (getRepresentation, getVariants, post, put, delete, etc.). It could also clarify things by renaming "post(Rep.)" to "postRepresentation(Rep.)" to be more consistent with "getRepresentation(Variant)" namine and to reduce the confusion with lower-level Uniform handle* methods. What do you think? What is your ideal design for the Resource class? Best, Jerome 2007/10/11, Chuck Hinson <[EMAIL PROTECTED]>: > On 10/10/07, Sean Landis <[EMAIL PROTECTED]> wrote: > [...] > > We have about a dozen people writing web services using Restlet. Although > > head is confusing, I'd say we experience more confusion over the fact > > that GET is a 'special case'. That is, there's no get(), but instead you > > must use getRepresentation(). So far, every single developer here has > > stumbled > > on this and required explanation. I'm afraid I can't give a rationale, I > > just tell them that's the way it is. > > > > Sean > > > > +1 > > I've had the same experience with my group, and like Sean, I am at a > loss as to how to explain why it has to be this way. > > At this point, i don't have a suggestion for how to resolve this, but > I do think it violates the principle of least surprise (in a sort of > roundabout way), and probably should have some effort devoted to > determining whether this approach is worth the cognitive overhead it > imposes. > > --Chuck >
