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

From: Tatu Saloranta <>
Date: Mon, 15 Feb 2010 14:14:54 -0800

On Mon, Feb 15, 2010 at 10:43 AM, Markus Karg <> wrote:
>> > We need to come with a number of patterns that can be applied to use-
>> cases and have corresponding prototype implementations and from all
>> that we will be able to hopefully define really good client and server
>> hypermedia API support!
> I need to disagree. I did never discuss "how to do hypermedia APIs". I am
> discussing what is HATEOAS and REST, and what is not HATEOAS and REST. It is
> absolutely valid and sensible what "they" want to do. All I say is that I
> don't want to have it in JAX-RS, since it is not REST, as it is not HATEOAS
> -- and JAX-RS is about REST, not about "anything with hypermedia via http".

I do not think most users would agree with this sentiment.
I am not even sure significant number of developers would agree. For
an open source project (and/or somewhat open standardization process)
this matters.
This is not to say that proposal has to be included -- it is a worthy
discussion in itself, and I do understand point of deferring solution
to client-side (and relevant APIs, frameworks, modeling) if that makes
sense. That may even be the right thing to do.
But I do not think this is done by proclaiming that since something is
not REST, it can not be included in JAX-RS, unless this is what JAX-RS
specification and reference implementation project state as the goal.

So: developers involved with JAX-RS process: is there such strict
relationship? How does JSR-311 position itself here? Am I right to
assume that it is more along "inspired by REST" ("that other web
service thing that is not SOAP") than strictly defined by REST?

-+ Tatu +-