Re: [Jersey] Jersey's (experimental) approach to support hypermedia constraint

From: Santiago Pericas-Geertsen <Santiago.Pericasgeertsen_at_Sun.COM>
Date: Wed, 10 Feb 2010 08:37:55 -0500

Hi Jan,

 Thanks for the feedback. This is precisely what we were looking for. As Paul pointed out, this is all experimental at this point.

> 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.

 We have looked at links in representations as well. There's more to be done in this area, but it is more difficult for the framework to help.

> 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.

 I guess I prefer to propose something, try it out and learn from it instead. Originally, we had all this work in a branch, but decided to move it to the trunk so that people can try it out and provide feedback. Besides, there are other REST frameworks exploring these type of extensions too. Hopefully, we can learn from all these experiments and come up with the right solution.

> 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) :-)

 This is a very good point.

> Putting something like 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.

 What REST constraint is that violating? How could a bot be programmed without the basic knowledge of things like pay, ship, etc.?

> 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.

 May be worth separating JS311 from Jersey in this discussion. All we have proposed is an experimental extension to Jersey.

-- Santiago

> 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]
>> [2]
>> -----------------------------------
>> Jan Algermissen, Consultant
>> NORD Software Consulting
>> Mail:
>> Blog:
>> Work:
>> -----------------------------------
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> -----------------------------------
> Jan Algermissen, Consultant
> NORD Software Consulting
> Mail:
> Blog:
> Work:
> -----------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: