Re: Link and Unlink

On Mon, Oct 8, 2012 at 8:07 PM, Manger, James H <
James.H.Manger@team.telstra.com> wrote:

> Using Link as an HTTP request header to convey  a link that you want to
> appear as an HTTP response header only works if requests can never have
> their own Link headers. Is this true?****
>
> **
>

It may not be obvious but LINK is not really intended to "convey links that
you want to appear as an HTTP response header".. in fact, the LINK method
itself really has nothing to do with what appears within response
headers... it is just a method that can be used to create an explicit
relationship between two resources, and within that request, the Link
header is used to convey the type of link to establish. In this case, I'm
only defining what Link means within the LINK and UNLINK methods and
nothing else.


>  **
>
> It might be better architecturally to send a PATCH request with the new
> Link headers in the body with, say, an application/header-patch media type.
> ****
>
> **
>

-1.. the main point of LINK/UNLINK is so that links can be established
independently of the specific resource or it's representation.


> **
>
> Perhaps it depends on whether links are particularly special (warranting
> dedicated HTTP methods), or whether they are basically content metadata(not
> that different from, say, content-type).
>

This depends entirely on the application case. There are many application
cases I can point to where creating a link between resources is an activity
rather than just a part of the metadata. In such cases, having a LINK
method makes far more sense than dealing with how links happen to be
represented with a particular data format. In fact, there are a large
subset of those cases in which it wouldn't make any sense at all to
serialize the existing links even tho they exist (pub/sub type scenarios
are one such example).


> ****
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *From:* James M Snell [mailto:jasnell@gmail.com]
> *Sent:* Tuesday, 9 October 2012 7:28 AM
> *To:* ietf-http-wg@w3.org
> *Subject:* Link and Unlink****
>
> ** **
>
> For review and comment...****
>
> ** **
>
>   http://www.ietf.org/id/draft-snell-link-method-00.txt****
>
> ** **
>
> Updated definition of LINK and UNLINK, taking RFC5988 into consideration
> and using language consistent from current httpbis draft (read: shamelessly
> and remorselessly lifted).  ****
>
> ** **
>
> Comments and feedback definitely welcome.****
>
> ** **
>
> - James****
>
> ** **
>