> Do the Restlet docs really say this? If so, those docs are sending a deeply > misleading message and should be fixed.
They definitely imply that. They take what appear to be standard (if simplistic) business methods, mark them up and it all works. But they is no mention anywhere (that I could find) of the restriction on the interfaces that you can enact. IMO to make those restrictions visible at runtime a client or server side exception should be thrown if the target method does not meet the underlying requirements of the architecture. The at least developers would know right away that their understanding is at fault, rather than their implementation. > 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. Fine, and I admit I have been thinking about this solely in terms of Java actors at both client and server. But as I pointed about above there is no runtime mechanism to let you know that what you are doing does not conform with the Restlet's implementation assumptions . > > 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? Possibly. Again see my points above. The examples and doco do nothing to make it clear the difference between the two. And in fact I would argue the Java examples do a lot to make them seem the same. > 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. Well the additional code for the marshalling in Java is trivial. I'd estimate it's probably cheaper than modifying all the examples and code to make it clear that you can't supply more than one param. > 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? :-) Well, I'd start by documenting the structure of the single object that needs to be transmitted across the wire. > And if someone else prefers a > different mapping mechanism, why should your mapping be enshrined in > Restlet? All I'm talking about is a (backwards compatible) transport mechanism that bundles multiple params into a single param as part of the marshalling. This is no different to the current mechanism in Restlet, just an expansion on it. So I don't understand your comment about having "my" mechanism 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. Perhaps JAX-RS is what I should be using. I just looked over Restlet, it seemed to have the right level of depth and detail and I guess I was mislead by the examples and doco over exactly what it does and doesn't do. This isn't a problem for me and I'm not trying to start some flame war over a particular implementation. I'm trying to contribute back after blowing 2 weeks trying to decipher what I would have expected to have realised in 5 mins. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3004344
