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

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 15 Feb 2010 17:21:32 -0500

On Feb 15, 2010, at 5:14 PM, Tatu Saloranta wrote:

> 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?
Here are the original goals: