[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/
-----------------------------------