On Aug 2, 2011, at 7:44 PM, Sergey Beryozkin wrote:
> Hi Jan
>
> I think the lower the cost of entry the better and absolute URIs do provide that low level IMHO.
What cost of entry?
> Of course, in the ideal world, all clients will follow RFC recommendations,
Well, then where do you draw the line? What about the clients that do not properly implement HTTP in the first place? What about clients that do not understand all the response status codes? Should we stop sending 409, 406 etc. just because some clients might not treat them as 400 in case they do not implement them directly?
> but in some case they won't and in some cases servers will forget providing
> info such as xml:base, etc.
And? You always have the proper context by definition through the request URI. No need for xml:base ... and what is 'etc.', BTW?
> It may sound like I want to continue looking for hypothetical examples but I don't. And it's not about dictating how the spec should evolve.
> Also, personally I don't consider the concern about the message size as being important too.
Huh? Granted, using REST in the first place rules out bit-squeezing, but doubled or so sizes when you serve millions of responses seems to be something worth to be concerned about.
> Users can easily switch to using relative URIs if we have
> 50KB payloads with absolute links contributing 20% to the total size
Still seems weird to me to make the 'low entry barrier' or 'if you have few or small messages' -solution the default on one of the leading HTTP implementations.
<shrug/>
Jan
>
> Cheers, Sergey
> P.S sorry - still can't use a proper email client so has to resort to S.B comments or to replying at the top of the reply message
> ________________________________________
> From: Jan Algermissen [algermissen1971_at_me.com]
> Sent: 02 August 2011 14:36
> To: Marek Potociar
> Cc: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>
> 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
>>>>>
>>>>
>>>>
>>>
>