Paul,
I think we're on the same page when it comes to the HATEAOS part. It
is the Java language mapping in general, and your example in
particular, that I was commenting on.
*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.
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.
-- Santiago
On Dec 3, 2009, at 10:29 AM, Paul Sandoz wrote:
>> Is there a bootstrap process in your brain that you can dump?
>>
>
> Imagine you have one bootstrap URI. And then you could drive all
> interactions by the client receiving links (and instructions how to
> construct new links e.g. think HTML forms) from the representations
> returned by the server. When a client traverses to a new link it
> makes a state transition to a new application state. The server
> defines the set of possible state transitions as links in the
> representations it returns. The client can choose to transition
> based on the type of the link (and perhaps additional meta-data in
> the representation associated with the link).
>
> So it s really a state-based machine. And what we want to proxy or
> encapsulate is, given a representation, one or more typed link to
> execute state transitions.