Jerome Louvel <contact <at> noelios.com> writes: > 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
Hi Jerome, What is the motivation of the Handler class? I have no problem with it, I just want to understand. Is it merely to be explicit about lower level API and higher level, or is there more to it? > 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(). I like the idea of mapping well to the REST terminology. > Feed-back welcome. It seems alright but there's enough there that I hesitate to endorse whole- heartedly without trying it out. That's when I usually can establish my comfort level best. > > Best regards, > Jerome Sean
