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

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"

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.

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.

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

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).

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)

Is that a better answer?

- James

On Tue, Nov 5, 2013 at 5:22 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2013-11-06 02:18, James M Snell wrote:
>>
>> It exists because (a) I couldn't come up with any viable, non
>> theoretical use cases where other attributes would really matter and (b)
>> the current model works in practice for everything I've done with it.
>
>
> James, that's an explanation why you think it's ok to add that constraint,
> but it doesn't explain why it's *needed*.
>
> If you took it out, would that cause any problems somewhere else?
>
> Best regards, Julian
>

Received on Wednesday, 6 November 2013 02:53:46 UTC