On Dec 3, 2009, at 9:15 PM, Santiago Pericas-Geertsen wrote:
> 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.
>
OK.
> *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 whether one is using a
dynamic language or not and one presumably needs to handle the case
when the "cancel" transition is not available.
There is coupling is REST but it is well thought out to enable both
the client and server to gracefully evolve over time. I think the
problem with machine-based REST is how and why to make the state
transitions, namely what information is required to be sent by the
client to the server. I think machines may couple more so in this
respect that browsers with HTML forms where the human fills in the
date. It is possible to reuse HTML forms or come up with an
alternative so that would could say write a JavaFX app to process the
data generically (this should be possible with the RESTful GF admin
interface).
> 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.
Paul.
> -- 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>