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

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

Received on Wednesday, 6 November 2013 15:12:00 UTC