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?
> 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?
-- Santiago