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

From: Markus Karg <>
Date: Tue, 16 Feb 2010 18:27:25 +0100

I don't understand your problem with the existing phrases. The target of
JAX-RS is to provide a Java API for REST. Not for anyhting else. And REST is
about HATEOAS. And the proposal contains *parts* that will fulfill that, and
*parts* that are not. So we shouldn't change the phrasing of what the target
of JAX-RS is, but just drop the non-HATEOAS parts in favour of the
HATEOAS-valid parts. Don't you agree?

> -----Original Message-----
> From: Tatu Saloranta []
> Sent: Montag, 15. Februar 2010 23:39
> To:
> Subject: Re: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What
> HATEOAS actually means)
> On Mon, Feb 15, 2010 at 2:21 PM, Marc Hadley <>
> wrote:
> > On Feb 15, 2010, at 5:14 PM, Tatu Saloranta wrote:
> ...
> >> 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:
> >
> >
> 40001.2
> Goals focus on "general REST-like" aspects: using HTTP as the transfer
> protocol, allowing for content-type independence (or loose coupling)
> and so on. But they do not state REST as the paradigm to follow or
> enforce.
> REST is still prominently mentioned in the Introduction: "This
> specification defines a set of Java APIs for the development of Web
> services built according to the Representational State Transfer[1]
> (REST) architectural style", which its exact role little less clear.
> Given this, would it make sense to rephrase proposals to explain what
> is being tried (something lie "how to add framework-level support for
> handling dynamic resource references"?) instead of using existing
> acronym (HATEOAS) which may not be applicable as per definition?
> Although it is convenient to use existing acronyms, it is better to
> focus more on goals instead of methods to reach the goals, since
> particular acronyms (REST, HATEOAS) focus on general architectural and
> design aspects and may not be the way to go for solving the problems.
> Especially ones related to machine-to-machine interaction, which is
> much more important for JAX-RS (and Java in general) than
> browser-based interaction.
> -+ Tatu +-
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: