On 08/02/2011 03:36 PM, Jan Algermissen wrote:
>
> 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).
Ok, I hear your point. Didn't take into account performance of small message payloads.
>
>> 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.
Thanks. Giving it a second thought, it seems to make sense to just support it but not make a default for performance
reasons. Or maybe we could just abstain from defining the default behavior. Will be able to tell once we have the API
code at hand.
Marek