On Feb 15, 2010, at 11:38 PM, Tatu Saloranta wrote:
> 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.
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
applications.
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.
Paul.