W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012


From: James Snell <jasnell@gmail.com>
Date: Mon, 23 Jan 2012 21:06:49 -0800
Message-ID: <CABP7Rbdo9VVF+7s8RBUd7POa9vGH-2f9GRk4e4ibqBz3HPLCgg@mail.gmail.com>
To: ietf-http-wg@w3.org
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

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

- James
Received on Tuesday, 24 January 2012 05:07:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:56 UTC