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

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 11 Feb 2010 21:18:10 +0100

On Feb 11, 2010, at 9:00 PM, Jan Algermissen wrote:

> On Feb 11, 2010, at 6:19 PM, Paul Sandoz wrote:
>> On Feb 11, 2010, at 4:39 PM, Jan Algermissen wrote:
>>> The most interesting part of this distinction is probably how it
>>> influences media type design (which is still a very nebulous
>>> area). The way you design a bunch of media types directly affects
>>> how flexibly the client can pursue its goals. It would be great to
>>> distill that into a principel for media type design.
>>> Example: if certain transitions are readily available from any
>>> state (e.g. via a Link: <..>;rel=service clients face less of a
>>> burden than if the availability of a transition requires several
>>> other transitions to be made before. Media type design can affect
>>> how RESTful your client side implementation is.
>> If i understand what you are saying then, interestingly, one could
>> view WADL support in Jersey in that sort of light. It is available
>> from any state using OPTIONS.
> Yes, correct. I would not use OPTIONS though because the answer is
> not cachable and you'd need to call it pprior to every request. A
> simple link would do just fine:
> Link: </service/global-hints.wadl>;rel=service;type=application/wadl
> +xml
> Link: </service/global-hints.rdf>;rel=service;type=application/rdf+xml

Yes, i was discussing with Santiago about a parallel URI structure for
WADL rather than using OPTIONS.

> (But please note that I would still discourage the overall approach
> as it seems to not focus on business level document design)

I think there may be potential for WADL to aid in the process by
providing "standard" service type descriptions. Jury is still out on
that of course and requires more experimentation. The annotated
linking approach presented by Marc will enable us to describe the
links in WADL and thus may give an opportunity for tooling to crunch
something to aid developers writing clients.

> It would be RESTful though given that the links link to runtime form
> information.
>>>> Haven't had a chance to read your blog yet, but I think it would
>>>> useful if you can put together a running example (using Jersey
>>>> perhaps? :)
>>> Working on it (see some other reply in this thread)
>> Great. Looking forward it. If you want to work in a branch of
>> Jersey let me know and i will grant you committer rights.
> When time has come I'll come back to that. I'll need a couple of
> iterations on my HD first :-)


> Are there any procedures, guidelines or coding styles for the Jersey
> work I need to read first?

There is nothing documented. It is very light weight:

1) use SE 5 for a new module unless you have a good reason to use SE 6.

2) public APIs should be documented.

3) work in a branch until something is considered stable to be part of
the release process.

For consistent formatting i would actually like to use a tool, but i
have never got around to sorting that out [*].


[*] I prefer explicit imports rather than foo.* and would like a tool
to enforce that (different IDEs have different preferences for that).

> Jan
> BTW: are you located in Europe? Maybe a F2F would at some point
> really help.

Grenoble, France.

Want to chat on the skype/phone next week?