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


From: Robert Sanderson <azaroth42@gmail.com>
Date: Tue, 24 Jan 2012 10:34:40 -0700
Message-ID: <CABevsUH3u0SVfwtGzz_jGQSADQBEgR4=3g+MD8EE5pO6JC0i3g@mail.gmail.com>
To: James Snell <jasnell@gmail.com>
Cc: ietf-http-wg@w3.org
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

On Mon, Jan 23, 2012 at 10:06 PM, James Snell <jasnell@gmail.com> wrote:
> 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
Received on Tuesday, 24 January 2012 17:35:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC