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

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 16 Feb 2010 07:50:47 +0100

On Feb 15, 2010, at 11:38 PM, Tatu Saloranta wrote:

> 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:
>> spec3.html#x3-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.

It is hard to enforce REST constraints in an API such as JAX-RS (a
developer can always implement GET with side-effects). I always like
to say that JAX-RS can help "guide" the developer to apply the REST
constraints when using HTTP, but for practical engineering reasons it
should be possible to break one or more of those constraints.

> 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.

My preference would be to state that we want to improve the hypertext
support in Jersey/JAX-RS when using HTTP. And thus developers can use
that support to apply the REST hypertext constraint to their Web

It may be there are two machine-to-machine hypertext use-cases
emerging: technical-based hypertext support; and business level
hypertext support.

Hopefully we can clarify this further with more concrete examples.