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 [mailto:tsaloranta_at_gmail.com]
> Sent: Montag, 15. Februar 2010 23:39
> To: users_at_jersey.dev.java.net
> 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 <Marc.Hadley_at_sun.com>
> 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:
> >
> > https://jsr311.dev.java.net/nonav/releases/1.0/spec/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.
> 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: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net