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.
>
> 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.
>
> 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)
> of an active client that implements your ideas. That would disprove my current thinking that this is one of those cases in which the difference between theory and practice is greater in practice than in theory.
Yes...
Jan
>
> -- Santiago
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen_at_acm.org
Blog:
http://www.nordsc.com/blog/
Work:
http://www.nordsc.com/
-----------------------------------