> >>> 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.
>
> 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.
I didn't want to say that JAX-RS must prevent people from doing non-REST,
but I wanted to say that JAX-RS should not motivate to do so (or even do
non-REST things by itself).
> > 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
> applications.
Okay, so at least *I* misunderstood the proposal: I thought the target was
to do HATEOAS (exactly that, in the REST sense), not to just "anyhow"
support hypertext.