On Feb 16, 2010, at 6:49 PM, Markus Karg 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.
>
> 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).
>
Agreed.
I also like to say that the developer needs to understand the REST
constraints and understand the pros and cons they introduce. And, that
it is OK not to apply all the constraints of REST as long as one
understands what consequences that has on the application
architecture. It is not something i would encourage but i can
understand why that needs to happen when solving certain practical
engineering problems.
>>> 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.
>
I often interchange hypertext or hypermedia with HATEOAS because it is
easier to say and write. Apologies if i confused matters.
An API cannot "do HATEOAS" anymore than it can "do REST". Only an
application can apply the REST constraints to its architecture to
induce the desirable properties.. An API can make it easier to apply
those constraints. We want to make it easier for developers to "do
HATEOAS" with their applications.
Paul.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>