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

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

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:

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