On Aug 2, 2011, at 2:47 PM, Marek Potociar wrote:
>
>
> On 08/01/2011 11:46 PM, Jan Algermissen wrote:
>> Sergey,
>>
>> On Aug 1, 2011, at 9:55 PM, Sergey Beryozkin wrote:
>>
>>> Meaning that all type of clients can understand how to work with a given link.
>>> Example, if say I'm using a generic Atom reader which gets a feed with rel links bubt without xml:base then
>>> if we can find at least 1 client that fails to convert rel links to absolute ones then I'd say using relative links in
>>> that specific context is not interoperable
>>
>> Such a client would be broken because the relevant specs thoroughly define how to turn relative URI references in links into absolute URIs to be used to request the link target.
>>
>> Finding broken client implementations should not guide new specifications. (Errm .... reminds me of HTML5 WG discussions...)
>
> Jan,
>
> The way I understand it, Sergey is just supporting the idea to make the absolute references a default option in JAX-RS
> API, so that by default the API can support also (potential) ill-behaved clients.
I do not think that ill-behaved clients should guide design decisions. Cluttering all my payload up with redundant information per default only increases message size (maybe even significantly - in contexts with only few textual data, you can easily double the message size).
> Such behavior is IMO a variation to
> Postel's Law.
I'd say, that Postel's law emphasizes to fix the *client* to be liberal in what it accepts and not to code the server to code with client defects in mind.
> Do you have any particular concerns with this?
Yes: really unnecessary payload increase as a default. Seems more logical to make absolute URI references sth that has to be turned *on* explicitly.
Jan
>
> Marek
>
>>
>> Jan
>>
>>
>>>
>>> Cheers, Sergey
>>> ________________________________________
>>> From: Markus KARG [markus_at_headcrashing.eu]
>>> Sent: 01 August 2011 17:59
>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>>>
>>> Interoperable in which context?
>>>
>>>> -----Original Message-----
>>>> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
>>>> Sent: Sonntag, 31. Juli 2011 21:43
>>>> To: Sergey Beryozkin; jsr339-experts_at_jax-rs-spec.java.net
>>>> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>>>>
>>>> I guess saving payloads with embedded absolute links is also not
>>>> guaranteed to be perfectly 'restorable' - the absolute server address
>>>> may change, but overall using absolute URIs seem to be OK for basic
>>>> default cases,
>>>> IMHO It's not a big deal in the end of the day if relative links assume
>>>> the default value, likewise I don't think it's a big deal if absolute
>>>> URIs are used by default - the question to experts is which form is
>>>> more interoperable,
>>>>
>>>> Sergey
>>>> ________________________________________
>>>> From: Sergey Beryozkin
>>>> Sent: 31 July 2011 20:31
>>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>>> Subject: RE: [jsr339-experts] Re: Hypermedia - Take 2
>>>>
>>>> Markus, I think we've just got sidetracked.
>>>> I've been advocating the use of @Ref.ABSOLUTE being the default value
>>>> and you are saying that relative links work great which to be honest
>>>> I'm not disputing :-).
>>>> I'm saying ABSOLUTE are always guaranteed to work; working with
>>>> relative links may present certain challenges - I don't want to offer
>>>> hypothetical examples, but
>>>> I hope you can agree that working with ABSOLUTE uris is more
>>>> straightforward and obviously is as RESTful as working with relative
>>>> URIs
>>>>
>>>> Sergey
>>>> ________________________________________
>>>> From: Markus KARG [markus_at_headcrashing.eu]
>>>> Sent: 29 July 2011 17:08
>>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>>> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>>>>
>>>> I don't understand this problem actually. If a client receives a
>>>> document
>>>> with absolute links, that would be no problem for the client. So if the
>>>> server sends relative links, nice. If not, where's the problem? Again,
>>>> REST
>>>> was discovered by looking at the web, and the web uses relative links
>>>> quite
>>>> a lot. So I do not see why we always discuss about problems. Let's
>>>> discuss
>>>> about solutions. If the web is working, JAX-RS can also made working.
>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
>>>>> Sent: Dienstag, 26. Juli 2011 22:56
>>>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>>>> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>>>>>
>>>>> Sorry, replying at the start of the message as we have an internal
>>>>> email migration and the web-based client does not append '>'
>>>>> properly...
>>>>> The problem is that we can not guarantee the server will build
>>>> relative
>>>>> links relative to the current request URI unless we always assume
>>>> JAX-
>>>>> RS 2.0 declarative hyperlinking feature is always
>>>>> used there at the other end which can not be guaranteed.
>>>>>
>>>>> thanks, Sergey
>>>>>> Anyway, you did not comment on what I said about the ambiguity to
>>>> do
>>>>>> with getting a payload with relative links after
>>>>>>
>>>>>> link.request().get()
>>>>>> and
>>>>>> link.path("bar").request().get()
>>>>>>
>>>>>> should the client resolve the rel links against
>>>>>>
>>>>>> basePath or basePath + "bar" ?
>>>>>>
>>>>>> I'm not saying we should not support relative links, I just feel
>>>>>> absolute URIs are more interoperable which is important
>>>>>
>>>>> There is no single base URI for the client but only a base URI for
>>>> the
>>>>> request and all the subsequent requests *internally* executed to
>>>> build
>>>>> the
>>>>> complete document tree of *that* request (it is a difference whether
>>>>> the
>>>>> application executes two requests against the same base URI, or
>>>> whether
>>>>> the
>>>>> JAX-RS runtime has to run several GETs to resolve a document tree
>>>>> spanned
>>>>> from relative hypermedia resolution).
>>>>>
>>>>> So in the first case link.request().get() it resolves against
>>>> basePath,
>>>>> and
>>>>> in the second link.path("bar").request().get() it resolves against
>>>>> basePath\bar.
>>>>>
>>>>> I do not see any ambiguity here, as the resolution is done within the
>>>>> "get()" execution, not any later. As soon as get() returns, the
>>>>> document is
>>>>> already built (it does not contain any URIs anymore -- remember, my
>>>>> proposal
>>>>> was to load them on the fly and replace them by their original data
>>>>> type!).
>>>>>
>>>>> Regards
>>>>> Markus
>>>>
>>>
>>>
>>