yes, I em working in designing a fully dynamic service and its
consumers .. not easy..
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
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.
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...
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