On Feb 15, 2010, at 5:14 PM, Tatu Saloranta wrote:
> On Mon, Feb 15, 2010 at 10:43 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
>>>> We need to come with a number of patterns that can be applied to use-
>>> cases and have corresponding prototype implementations and from all
>>> that we will be able to hopefully define really good client and server
>>> hypermedia API support!
>>
>> I need to disagree. I did never discuss "how to do hypermedia APIs". I am
>> discussing what is HATEOAS and REST, and what is not HATEOAS and REST. It is
>> absolutely valid and sensible what "they" want to do. All I say is that I
>> don't want to have it in JAX-RS, since it is not REST, as it is not HATEOAS
>> -- and JAX-RS is about REST, not about "anything with hypermedia via http".
>
> I do not think most users would agree with this sentiment.
> I am not even sure significant number of developers would agree. For
> an open source project (and/or somewhat open standardization process)
> this matters.
> This is not to say that proposal has to be included -- it is a worthy
> discussion in itself, and I do understand point of deferring solution
> to client-side (and relevant APIs, frameworks, modeling) if that makes
> sense. That may even be the right thing to do.
> 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
Marc.