- From: James Snell <jasnell@gmail.com>
- Date: Tue, 24 Jan 2012 09:58:04 -0800
- 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 UTC