On Thu, Sep 6, 2012 at 6:13 PM, William Ferguson < william.fergu...@xandar.com.au> wrote:
> > As Jerome hinted, it would be great if someone who had such expectations > > could think back to how those expectations arose and then offer tweaks to > > the docs/javadocs that would prevent others from making the same > > assumptions. > > I think they arise because you are told to craft an interface containing > business methods, annotate them with HTTP methods and implement that on > client and server. > Do the Restlet docs really say this? If so, those docs are sending a deeply misleading message and should be fixed. > But business methods don't (and shouldn't) have a restriction on them to > only have a single parameter. > Right, but Restlet supports the uniform HTTP interface, not a more general notion of Java interface. Sticking to a uniform interface is important for interoperability with non-Java clients/components. > Dynamic proxies have been used to marshall/unmarshall remote method calls > for the last 10 years and I think most developers have come to expect a > certain level of functionality from that. > Could it be that people are confusing Restlet with JAX-RS? > Instead of modify the documentation to prevent others from expecting > Restlet to handle multiple params, I'd be more inclined to modify the code > to allow it to happen. I suspect it would also be the cheaper of the two > options. > What do you mean by "cheaper of the two options"? Restlet as it stands is pretty streamlined; it's hard to see how adding further magical behavior could be anything but more expensive. It would be nontrivial to "modify the code to allow it to happen". It's not as if this functionality already exists and just needs to be enabled. There are a lot of questions to answer: How would you map between generic Java interfaces and the uniform HTTP interface and still preserve the option of having non-Java clients and servers? And if someone else prefers a different mapping mechanism, why should your mapping be enshrined in Restlet? Is JAX-RS closer to what you're looking for? Or why not simply write your own business layer on top of the Restlet layer? That way you can control how parameters are conveyed over HTTP (via URI template variable, HTTP header, or as part of an entity) without having to settle for someone else's notion of how to do it. --tim ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3004274
