users@jersey.java.net

Re: [Jersey] Generating WS client based on reflection

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 03 Dec 2009 23:15:58 +0100

On Dec 3, 2009, at 10:47 PM, Santiago Pericas-Geertsen wrote:

>
> On Dec 3, 2009, at 3:32 PM, Paul Sandoz wrote:
>
>>> *If* actions leading to valid states are truly discovered
>>> dynamically (a notion that I'm still struggling with due to the
>>> human vs. bot discussion) then,
>>>
>>> order.cancel()
>>>
>>> won't work in Java as cancel() must be known statically (with
>>> 'order' being a proxy instance). Looking at the RESTfulie docs,
>>> they would write:
>>>
>>> resource(order).getTransition("cancel").execute()
>>>
>>> in the case of Java. In Ruby, methods can be added dynamically and
>>> there's no static typing, so the story is quite different.
>>>
>>
>> IMHO this still couples to the link types
>
> How so?

Because .cancel() or "cancel" is declared in the code. And underneath
there presumably has to be some knowledge about the application/xxx
+xml media types and representations of that contain "cancel" typed
links.


>
>> whether one is using a dynamic language or not and one presumably
>> needs to handle the case when the "cancel" transition is not
>> available.
>
> Yes.
>
>>> Dropping the decoupling premise in the *If* above, then I think
>>> certain artifacts could be generated statically that would permit
>>> better use of the Java type system while still enabling better
>>> server evolution by hiding (and dynamically binding) actions to
>>> URIs.
>>>
>>
>> Yes, i think a general solution as well as generating interfaces/
>> proxies/classes that correspond to the link types and execution of
>> the state transition is appropriate and such static generation does
>> not IMHO break the REST hypermedia constraint.
>
> Great. But how is this form of coupling different from the one you
> disliked above?
>

There is less of it.

A good example of increased coupling was (i dunno if it is now) the
OpenSocial API which Roy commented on [1]. IIRC OpenSocial mandated
that each implementation use the same URI structure, rather than
letting each implementation define their own, with OpenSocial defining
the media types and link relationships.

Essentially the proxy-based approach defines resource types on the
client side.

Paul.

[1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven