Re: [Jersey] Jersey's (experimental) approach to support hypermedia constraint

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 11 Feb 2010 18:19:08 +0100

On Feb 11, 2010, at 4:39 PM, Jan Algermissen wrote:

> On Feb 11, 2010, at 3:57 PM, Santiago Pericas-Geertsen wrote:
>> On Feb 11, 2010, at 9:17 AM, Jan Algermissen wrote:
>>> Great! Given that you do not vehemently object to my qustion about
>>> the status codes it seems we are not that far apart :-)
>> :)
>> Still trying to catch up with this thread. So apologies if I'm
>> missing something. For the most part, I agree with your comments
>> and concerns.
> Great! So maybe not too much trouble ahead :-)
>> As you said, it is important to separate "active" vs. "passive"
>> clients. Active clients (having their own "agenda") are more
>> interesting to me as they relate more to the enterprise IMO.
>> Although, most of the things you stated apply to passive clients,
>> I'm still not convinced they apply to active ones.
> The most interesting part of this distinction is probably how it
> influences media type design (which is still a very nebulous area).
> The way you design a bunch of media types directly affects how
> flexibly the client can pursue its goals. It would be great to
> distill that into a principel for media type design.
> Example: if certain transitions are readily available from any state
> (e.g. via a Link: <..>;rel=service clients face less of a burden
> than if the availability of a transition requires several other
> transitions to be made before. Media type design can affect how
> RESTful your client side implementation is.

If i understand what you are saying then, interestingly, one could
view WADL support in Jersey in that sort of light. It is available
from any state using OPTIONS.

>> Active clients are more delicate and are driven by an agenda; as a
>> result, they should either carry our their agenda or report an
>> error indicating why they couldn't.
> Well, yes. At some point this is the last resort because there is no
> human behind it. My issue is primarily that a framework should not
> introduce coupling that REST aims to avoid. But instead should
> emphasize how much 'proactive' work should be done by the client in
> a RESTful system.


>> An active client that automatically reacts (e.g. a client that is
>> transferring funds between bank accounts) still scares me a bit,
>> especially if the decision on how to react is programmed in the
>> framework and not the application.
> Yes. We do not want some sort of fancy AI dealing with our system.

Can't let the machines take total control...

>> Haven't had a chance to read your blog yet, but I think it would
>> useful if you can put together a running example (using Jersey
>> perhaps? :)
> Working on it (see some other reply in this thread)

Great. Looking forward it. If you want to work in a branch of Jersey
let me know and i will grant you committer rights.