jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Hypermedia - Take 2

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 03 Aug 2011 14:38:30 +0200

On 08/02/2011 08:19 PM, Markus KARG wrote:
>>> Hi Marek
>>>
>>> My point is that the resolution of relative links is not entirely
>> portable.
>>> I'm not saying relative links can not be used effectively - what I'm
>> saying in the end of the
>>> day is that having ABSOLUTE being a default value of @Ref seems OK
>> for me,
>>
>> +1. Absolute as a default is obviously more interoperable (or portable,
>> to use your terminology).
>
> "Obvious"? Is it now commen sense that all what I propose has to be prooven, while all what some others say is "obvious"? I mean, you demanded that I shall proof that pub/sub is not RESTful, while you now declare something to be "obvious" that not only was objected by me but at least two times by other experts like Jan? Did I miss something here? Have we different status or amount of votes in what is "obvious" and what has to be prooven?

As explained in a separate reply to Jan, I was just conveying my support for Sergey's proposal. Should I be objecting, I
would have certainly listed my reasons.

>
> As long as one can enable relative mode, it plays no role whether it is more or less interoperable: It must work. If it does not, we must not provide that possibility at all. What shall it be good for to enable relative mode optionally if there are chances that clients cannot process it? So either we can safely use it as a default, or we can get rid of relative at all. I do not see a need for an option that bears the risk of breaking clients.
>
> And again, a client that is too dumb to resolve a relative link is by definition a broken one, regarding to the respective RFCs as mentioned by Jan.

Actually, it was me who mentioned the RFC.

>
>>> and back to your question,
>>> we don't know at the client side whether the relative links have been
>> created from the original base URI the client used or
>>> from the current URI, and 'should' is not a strong enough guarantee.
>> Saving payloads and restoring them afterwards may present
>>> another issue as far as the resolution is concerned.
>>
>> Can you provide an example. Seems I got lost again. Sorry :)
>
> Maybe we should start using moderated threads concentrating on one single proposal at one time. We all lose track too often. This is uneffective for all participants.

When I said that I got lost, I meant that I did not get the point. Not sure if moderated threads would help here.

Marek

>
> Regards
> Markus
>