Re: [apps-discuss] FYI: LINK and UNLINK

Whether and how a server surfaces links is undefined by this spec. There
are cases where exposing the link would be wholly unnecessary. There are
also cases where the server could significantly alter or augment the
established link with additional detail. My goal with this spec is only to
define the method characteristics.

Regarding the main question about whether or not to include target
attributes in the uniqueness constraint, the question becomes: which target
attributes should be considered?
On Nov 6, 2013 7:11 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> On 2013-11-06 03:52, James M Snell wrote:
>
>> Sorry, my answer was a bit abbreviated as I was heading out to help
>> coach the kids soccer practice... Mark's answer touched on the more
>> complete answer.
>>
>> The way this is defined, LINK (and UNLINK) are idempotent requests. If
>> I send the following request twice, the link
>> (/my/resource,"foo",/other/resource) still only exists once.
>>
>>    LINK /my/resource HTTP/1.1
>>    Host: example.org
>>    Link: </other/resource>; rel="foo"
>>
>
> Yes.
>
>  I could send a separate LINK request connecting the same two resources
>> using a different link relation.. creating a separate link...
>>
>>    LINK /my/resource HTTP/1.1
>>    Host: example.org
>>    Link: </other/resource>; rel="bar"
>>
>> No matter how many times I send that request, there is only one link
>> established.
>>
>
> Yes.
>
>  Whether or not additional target attributes and extension parameters
>> are considered is entirely up to how the server chooses to utilize the
>> link relationship. If, after I send the second request above, I send
>> another:
>>
>>    LINK /my/resource HTTP/1.1
>>    Host: example.org
>>    Link: </other/resource>; rel="bar"; title="this is the bar link"
>>
>> I would expect that -- if the server treats the target attributes as
>> something worth paying attention to -- the existing bar link (if one
>> exists) would be modified using the new attributes.
>>
>
> I agree that this makes sense for "title", but I'm not convinced that the
> same is true for every possible parameter.
>
>  Per your specific question, yes, we could take all of the target
>> attributes and extension parameters into consideration when
>> determining uniqueness of the link, but doing so would introduce
>> significantly more complexity, especially when one comes back later
>> and attempts to do an UNLINK -- the client would be required to
>> duplicate *all* of the target attributes/extension parameters used to
>> establish the original link.  For instance, suppose I did:
>>
>>    LINK /my/resource HTTP/1.1
>>    Host: example.org
>>    Link: </other/resource/1>; rel="foo"; hreflang="en"; ext=foo
>>    Link: </other/resource/1>; rel="foo"; hreflang="fr"; ext=bar
>>
>> And suppose that later on I want to UNLINK the second of the two, I
>> would have to send:
>>
>>    UNLINK /my/resource HTTP/1.1
>>    Host: example.org
>>    Link: </other/resource/1>; rel="foo"; hreflang="fr"; ext=bar
>>
>
> Yes. It would need to match all parameters. Why is matching all parameters
> more complex than matching one?
>
>  Which implies that my UNLINK'ing client has full knowledge of the
>> complete set of attributes used to establish the link in the first
>> place ... which it may not (remember, we currently have no
>> standardized way of enumerating all of the links that have been
>> established).
>>
>
> Wait. What's the point in LINK if the link that you create does not show
> up in a GET response? Maybe we need to clarify *that* first.
>
>  So, by defining the uniqueness constraint as (context,link
>> rel,target), we greatly simplify the model... and yes, that
>> simplification comes at the cost of some functionality -- but given
>> that I have not yet seen a viable, non-theoretical use case, I view
>> that loss as acceptable. I'm definitely open to be convinced otherwise
>> (for instance, I could quite easily be convinced that the hreflang and
>> type attributes ought to be considered part of the uniqueness
>> constraint)
>>
>
> What's the material difference from matching all parameters then?
>
>  Is that a better answer?
>>
>
> Yes.
>
> Best regards, Julian
>
>