On Feb 10, 2010, at 12:31 PM, Felipe Gaścho wrote:
> yes, I em working in designing a fully dynamic service and its
> consumers .. not easy..
Yes, hard. I am thinking about it since 2003 I guess (with interuptions :-)
OTH, given that the server then can pretty much evolve in any (non insane) way
why should one expect that it is easy to do the client side?
>
> my strategy is of using representations instead of actions.. but my
> productivity is much slower than the other guys due to resource
> constraints (a.k.a. "alone in spare time") :) eheh
Yeah, I know that one - hence 'with interuptions'. I have taken a
4 month break since November to work through some of the IMHO
un-researched areas of REST (applied to enterprise) and I really
takes time. Basically you just have to feed your barin and wait
until synapses reorganize and the insight pops up. Can't force
that.
>
> Nevertheless, the goal of making coding simpler in both sides is a
> very good thing.. and I can see the beauty of the Jersey approach.
I have come to like Jersey very much in the server side. and the client side
connector is also very fine. But please no messy layer on top of that :-)
>
> it is too early for conclusions, but I appreciate the Jersey work..
> and I am following restfulie as well - as a way to collect good ideas
> around the hateoas topic....
>
> let's see...
Yes.
Jan
>
> On Wed, Feb 10, 2010 at 12:00 PM, Jan Algermissen
> <algermissen1971_at_mac.com> wrote:
>> [follow up]
>>
>> I think there are different issues that need to be discussed separately:
>>
>> 1) What is the best way for a framework to support the
>> server side developer in the task of adding links to
>> the served representations?
>> In my experience it is often hard to separate the
>> creation of a domain object's representation from
>> the addition of links in order to adhere to good
>> programming practice. Usually I eventually have
>> to copy/paste some code (which I hate).
>>
>> In part this is a result from links being part
>> of the representations and sometimes also
>> being placed in headers.
>>
>> Framework support tp ease thsese issues would be
>> a good thing. But it would be purely server-side.
>>
>> 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.
>>
>> 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.
>> 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)
>>
>> Jan
>>
>>
>>
>>
>>
>>
>> On Feb 10, 2010, at 11:33 AM, Jan Algermissen wrote:
>>
>>> All,
>>>
>>> there has been some discussion yesterday on Twitter regarding [1] and Paul suggested to take this over to the list.
>>>
>>> As a start, here is the link to my initial criticism[2].
>>>
>>> I am working on a more detailed one today.
>>
>>
>>>
>>> Jan
>>>
>>> [1] http://weblogs.java.net/blog/spericas/archive/2010/02/09/exploring-hypermedia-support-jersey
>>> [2] http://www.nordsc.com/blog/?p=278
>>>
>>>
>>> -----------------------------------
>>> Jan Algermissen, Consultant
>>> NORD Software Consulting
>>>
>>> Mail: algermissen_at_acm.org
>>> Blog: http://www.nordsc.com/blog/
>>> Work: http://www.nordsc.com/
>>> -----------------------------------
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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/
>> -----------------------------------
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
>
>
> --
> ------------------------------------------
> Felipe Gaścho
> 10+ Java Programmer
> CEJUG Senior Advisor
>
> ---------------------------------------------------------------------
> 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/
-----------------------------------