Subject: LINK/UNLINK

From: James Snell <[email-masked]>
Date: Mon, 23 Jan 2012 21:06:49 -0800

I've been giving some thought lately to the fact that nearly every web
API out there currently deals with management of links between
resources.. we have apis for tagging people within pictures, apis for
friend requests, apis for a variety of social contacts, the list goes
on. RFC 2068 [1] had originally discussed a number of additional
methods including PATCH, LINK and UNLINK but these fell by the wayside
largely because, at the time, their utility was generally very
questionable. The more I look at existing APIs, however, the more I
think it's time these are properly revisited.

[1] http://tools.ietf.org/html/rfc2068#page-156

For example, creating a "friends" association between two user
profiles could be as simple as:

  LINK /profiles/@me HTTP/1.1
  Host: example.org
  Link: <http://foo.other.com/profiles/bob>; rel="friend"

Tagging people in an image could be done with...

  LINK /images/foo.jpeg HTTP/1.1
  Host: example.org
  Link: <http://foo.other.com/profiles/bob>; rel="tag"

Implementing the subscription management portion of a PubSubHubbub
style publishing model could be done as...

  LINK /activity/stream HTTP/1.1
  Host: example.org
  Link: <http://foo.other.com/monitor>; rel="monitor"

Then on the other side, removing the Link would be a simple...

  UNLINK /activity/stream HTTP/1.1
  Host: example.org
  Link: <http://foo.other.com/monitor>; rel="monitor"

Obviously links attached to a resource in this way could easily be
scoped to the authentication context and servers would be free to
implement the specific details in their own way, but by reintroducing
LINK/UNLINK methods could help to simplify Web-based APIs down the
road.

I'm considering writing up an Internet-Draft for this but wanted to
solicit feedback from the group first.

- James

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Jan 2012 16:22:49 +1100

On Jan 23, 2012 9:07 PM, "James Snell" <[email-masked]> wrot e
> solicit feedback from the group first.

Please do. I'm sure that you will gain a lot of interest. I'm nitty certain
that Link/unlink is necessarily the best semantics. Is this an idempotent
operation? Does link set the value of a relation as in put, or does it add
a new link of that type (post)?

I don't know what the right answer is or whether there is one, but I've
like to have the discussion.

--Martin

---

From: "Eric J. Bowman" <[email-masked]>
Date: Mon, 23 Jan 2012 22:26:58 -0700

> solicit feedback from the group first.

+1

I've also wondered if RFC 2068 wasn't on to something way back when, as
a means of manipulating my application/x.xbel+xml media type, which I
use to manage links.

-Eric

---

From: Robert Sanderson <[email-masked]>
Date: Tue, 24 Jan 2012 10:34:40 -0700

Dear James,

Thank you for proposing this work.  We've been using the link header
RFC as a fundamental part of our specifications over the last two
years and have several use cases that you might wish to consider for
the LINK/UNLINK verbs.  If that's of interest, I'd be happy to
describe them for you (off list?)

Hope that helps,

Rob Sanderson
Information Scientist at Los Alamos National Laboratory

---

From: James Snell <[email-masked]>
Date: Tue, 24 Jan 2012 09:58:04 -0800

Additional use cases are always a great thing. I would definitely
prefer discussion on list but I would not want to draw too much of
this groups attention on discussion about the new methods before a
draft is published and available. So if you would like to send a note
off-list detailing some of those use cases I can review them and
incorporate things as appropriate into the draft then open it up for
discussion after that.