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

Re: LINK/UNLINK

From: James Snell <jasnell@gmail.com>
Date: Tue, 24 Jan 2012 09:58:04 -0800
Message-ID: <CABP7Rbcj2UUWBEm30WM5gAB0_vzcvUMO9hXXXQC3iAZgau76+w@mail.gmail.com>
To: Robert Sanderson <azaroth42@gmail.com>
Cc: ietf-http-wg@w3.org
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.

On Tue, Jan 24, 2012 at 9:34 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 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:58:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:53 GMT