LINK/UNLINK

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

LINK/UNLINK

James M Snell
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

Reply | Threaded
Open this post in threaded view
|

Re: LINK/UNLINK

Martin Thomson-3


On Jan 23, 2012 9:07 PM, "James Snell" <[hidden email]> wrot e
>
> I'm considering writing up an Internet-Draft for this but wanted to
> 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

Reply | Threaded
Open this post in threaded view
|

Re: LINK/UNLINK

Eric J. Bowman-2
In reply to this post by James M Snell
James Snell wrote:
>
> I'm considering writing up an Internet-Draft for this but wanted to
> 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

Reply | Threaded
Open this post in threaded view
|

Re: LINK/UNLINK

Robert Sanderson
In reply to this post by James M Snell
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: LINK/UNLINK

James M Snell
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 <[hidden email]> 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 <[hidden email]> 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
>>