the client framework creates proxies for resource classes and now for 
subresource locators as well (see e.g. Issue 589). These are always 
created for the class indicated by the static return type of the 
respective method, e.g. for a resource locator with the method

Chapter getChapter(@PathParam("number") int number)

a proxy for "Chapter.class" is created and used. The jax-rs 
specification, however, states that "An implementation MUST dynamically 
determine the class of object returned rather than relying on the static 
sub-resource locator return type" (section 3.4.1). Thus, the server may 
actually use a subclass of "Chapter", and process the request in a 
different manner than expected by the client framework.

IMO, this basically means that Java interfaces alone cannot in all cases 
be used as the complete specification of the server's ReST interface, 
and consequently may be insufficient as basis for the client framework. 
Any thoughts on how to deal with this?


LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
Resteasy-users mailing list

Reply via email to