On Feb 10, 2010, at 1:07 PM, Paul Sandoz wrote:
>
> On Feb 10, 2010, at 12:00 PM, Jan Algermissen wrote:
>
>
>> 2) What is the proper way to design media types and
>> links?
>> I really (strongly) think that a framework should
>> either know exactly what it is doing or be silent
>> about this matter altogether.
>> Since the whole issue of machine2machine media types
>> is still not thoroughly analysed (IMHO) it is very
>> dangerous to promote a certain approch (re 'action
>> resources').
>> This is what caused my worries yesterday. Especially
>> since I think that the proposed approach misses the
>> point comletely.
>>
>
> This is research :-) which is always risky, but even in failure good lessons will be learned. You have to start somewhere with experimentation. So i am not sure you need to think of this as "dangerous",
Agreed. However, due to the exposure of Jersey people are likely to be influenced a lot by the approach Jersey takes.
> although the way i interpret that is you really care about this area and are extremely interested in seeing a good outcome.
Yes, definitely. I am very convinced that REST can greatly contribute to simplifying enterprise IT but people will only realize the benefits if it is done right. If done wrongly, REST will create a bigger mess in the enterprise than tightly coupled RPC and will be kicked out before the advatages have actually been realized.
I think that REST-inside-the-enterprise is in a very instable state right now because so many people now *think* they got it but actually don't. Too much hand waving. Clear guidelines for the average developer are missing. And Jersey's client side can go a long way towards helping with that (but also towards making it worse). Hence my (over-)reaction.
>
> I prefer to think of it as an exciting exploration that we are just starting out on :-)
Yes.
>
> What IMHO would be dangerous and very irresponsible is premature standardization.
Yes. But there is a danger of Jersy being quasi-standardizing...
Jan
>
>
>> 3) What is the proper way to implement a RESTful client?
>> This is in my opinion also not yet solved at all and
>> most approaches just introduce coupling between client
>> and server that REST aims to avoid.
>> As with 2) a framework should know exactly what it is
>> doing in order not to foster the proliferation of
>> unRESTful REST systems.
>> I am very concerned about this because I consider REST
>> done wrong to be worse then RPC done right. Mostly so
>> because unRESTful REST tends to introduce coupling that
>> is completely undocumented while with RPC we at least
>> have IDL class definitions. (Yes, I know this from
>> personal wrong doing (shame on me) :-)
>>
>> Putting something like order.pay() in the client code
>> violates RESTs hypermedia constraint because it hard
>> codes an assumption that REST does not support. In REST
>> there is no way to know at design time whether there
>> will be a 'pay' traversal froom the 'order'-state at all.
>> The right way to code the client here is to follow the pay
>> traversal *if* the steady state reached after a GET on
>> the order resource provides the necessary transition.
>
> It you take a look at the proxy implementation it is indeed doing something like that (as presented in the logged output). Internally states will be checked based on the link relationships in the representation. Although i think the error handling could be better.
>
> We decided that for a machine to machine approach exposing the link relationships as an interface can be useful both for development and tooling and i do not think it has to violate the REST hypermedia constraint for it to work.
>
> As long as the proxy does the right thing working correctly or throwing exception to react to unexpected cases i think it is just a slightly different programming model to what one might expect.
>
>
>> If it doesn't, the client must still handle the situation
>> (probably by trying something else, probably by logging
>> an error for human reaction).
>> Hiding this issue wil lead client side developers to
>> wrong assumptions about the nature of the architecture.
>>
>
>> Too many people are doing this already and I think Jersey/
>> JSR 311 should work against that trend instead of making
>> it worse.
>>
>> Having said all that - naturaly I have my own understanding
>> how it should work and I am happy to add this to the debate.
>> (Will be about one or two weeks before I can post that)
>>
>
> OK!
>
> Paul.
>
> ---------------------------------------------------------------------
> 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/
-----------------------------------