Hi Stephan, If you mean that because we use 4 annotations (note that JAX-RS has 19) it is a copy, then you are right ;-) Seriously, we are trying to solve a specific set of RFEs in the Restlet API. See details here: http://wiki.restlet.org/developers/172-restlet/226-restlet.html We are just looking for the best solution, whatever it is. Note that we would still extend a base class (ServerResource) that would would be like the current's Resource one and provide the current request/response and context. We just want to go one step further and automate, in some cases, the variants declaration and facilitate the representation generation based on the selected variants. Same need for the processing of PUT/POST methods based on the media type of the sent entity. I've also proposed another approach based on method naming conventions had some drawbacks. If you have a better idea, please let us know. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com
_____ De : [email protected] [mailto:[email protected]] Envoye : samedi 31 janvier 2009 21:51 A : [email protected] Objet : Re: Resource API refactoring (Was: media type adaptor) Hi Jerome, looks like a copy of JAX-RS to me. best regards Stephan Jerome Louvel schrieb: Hi again, I've just played with the annotations idea. I have to confess that used in this restricted way (only on methods), I'm starting to like it. Here is how a sample resource would look like with the refactored API. Note that both extension names and full MIME type would be supported. Extensions can be updated via the MetadataService. import java.io.InputStream; import org.restlet.ext.atom.Feed; import org.restlet.resource.Accepts; import org.restlet.resource.Removes; import org.restlet.resource.Representation; import org.restlet.resource.Represents; import org.restlet.resource.ServerResource; import org.restlet.resource.Stores; public class TestResource extends ServerResource { @Represents("atom") public Feed getAsAtom() throws Exception { // ... return null; } @Represents("application/custom+xml") public Representation getAsXml() throws Exception { // ... return null; } @Accepts public void post(Representation entity) throws Exception { // ... } @Stores("atom") public void putAtom(Feed feed) throws Exception { // ... } @Stores("application/custom+xml") public void putXml(InputStream stream) throws Exception { // ... } @Removes public void delete() throws Exception { // ... } } What is nice is that we would keep the higher-level terminology that we have in Restlet 1.1 (accept, store, etc.) but make it available in a more flexible and declarative way. The new ServerResource would only have lower-level methods, but with a more flexible signature than in Restlet 1.1: * void handle() * Representation handleGet() * Representation handleGet(Variant) * Representation handleHead() * Representation handlePost(Representation) * Representation handlePut(Representation) * Representation handleDelete() I think we are getting somewhere this time. Looking forward to your feed-back. Best regards, Jerome Louvel ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1092068
