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.
+1
>
>> 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.
Paul.