users@jersey.java.net

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

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 10 Feb 2010 22:31:55 +0100

On Feb 10, 2010, at 8:56 PM, Jan Algermissen wrote:

>
> On Feb 10, 2010, at 6:40 PM, Paul Sandoz wrote:
>
>> On Feb 10, 2010, at 4:21 PM, Jan Algermissen wrote:
>>> The only RESTful way to approach this is
>>>
>>> - GET /orders/2
>>> - dispatch on whatever media type we received (or on available
>>> headers)
>>> - if have-link-header 'pay' OR media type == application/order AND
>>> have pay-link in the representation THEN (and only then)
>>> - do a POST on the target of the pay link (we know this from
>>> corresponding spec (and maybe form in representation))
>>
>> The intent of the proxy implementation is to do something similar
>> to the above (but only link headers are currently implemented). But
>> it still needs better error handling.
>
> Hmm, sorry. I do not understand how the proxy approach tries to deal
> with several possible returned media types.

The controller defines the media types it accepts using @Produces and
one model type that can be produced from representations of those
media types. I agree this is just one particular approach (model +
action resources) but again this is just the start of our experiments.
(Once we get annotated links supported in representations things will
get more interesting.)

If the server decides one day to return a non-acceptable media type,
or a 406 response, then the client will fail, preferably with grace!


>
>>
>> Have you tried playing around with the example?
>
> I looked at the docs <https://jersey.dev.java.net/nonav/documentation/1.2-SNAPSHOT/user-guide.html#d4e1013
> > but I guess I just can't see what the problem is that this is
> trying to solve.

The proxy approach can bind to link types (rather than say binding to
resource types where URIs are explicitly declared) so client can
change the application state as declared in the link headers thus
making the client and server more loosely coupled.


> (But then, I find the whole aproach to hypermedia confusing (sorry)).
>


I think in essence hypermedia is very elegant and once grasped
surprisingly simple, but gosh it can take time to get your brain
thinking the right way about it, well it did for me :-)

IMHO a lot of confusion arises if one assumes machines to machine
hypermedia communication can be treated exactly the same as machine to
browser to human hypermedia communication.

Paul.