RE: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What HATEOAS actually means)

From: Markus Karg <>
Date: Thu, 18 Feb 2010 19:49:57 +0100

> JAX-RS allows developers to implement GET with side-effects or support
> cookies for session preservation. There is nothing we can do to
> prevent developers from doing that if they want to. I think the same
> thing applies with hypertext.
> What we can do, and is what we have done, is discourage such
> approaches and guide developers with presentations, examples and
> documentation (see Goal 2 i previously mentioned, which i think is
> especially important w.r.t. hypertext given the confusion it tends to
> cause).

I totally agree. That is why I would discourage the idea of a hypertext API
extension that allows to send links as "any" header, but instead is fixed in
a way that *only* will send as exactly the "Link" header, or as a plugin
system like extension to the MessageBodyWrite etc. that is putting the links
into the entity. But I would *not* provide the possibility to use any
headers without explicitly using headers "by hand" (instead of the hypertext
API extension), and I would *not* add the possibility of "RPC-style" URIs in
the hypertext API extension. If one will use the "normal" JAX-RS APIs to
send links as self-invented headers, or accept "RPC-style" URIs, then we
cannot do anything against it. But explicitly the hypertext API extension
should not support it from it's design.