Re: Link and Unlink

On Mon, Oct 8, 2012 at 5:49 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 09.10.2012 09:28, James M Snell wrote:
>
>> For review and comment...
>>
>>   http://www.ietf.org/id/draft-**snell-link-method-00.txt<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
>>
>
>
> Given that LINK/UNLINK contain the active parameters for change in Link
> headers instead of URL I don't believe they are normally cacheable as
> stated in the draft. Only when a proxy cache is performing conditional
> requests to the upstream server does cacheability make sense.
>
>
Definitely appreciate the detailed look through. I've been going through a
variety of use cases this afternoon and I'm less and less convinced that
allowing caching for link/unlink is useful for any reason whatsoever. I
can't really think of a single case where it may be worthwhile.


> [snip]
>
> That raises the question of whether, being idempotent the server should
> respond with "304 Not Modified" in all cases where the LINK/UNLINK was not
> performed due to the link already existing (or not). 204 seems to be a step
> in that direction while retaining the 200 semantics, but 204 *replaces* a
> 200 representation with 'nothing' - whereas 304 would simply be a no-op
> success.
>
>
There are a couple of cases worth considering...specifically, a LINK might
not create a new link, but it might modify an existing one.. namely when
different metadata (title, hreflang, etc) is provided and the link already
exists. Returning a 304 if the Link already exists and has not been
modified makes a lot of sense. This is a case that should definitely be
documented in the doc.


One of the other major questions that came up for me when thinking this
through is what if the Link Relationship itself can be created as a
resource? For instance...

Request:

  LINK /my-resource HTTP/1.1
  Host: example.org
  Link: <http://example.org/foo>; rel="foo"

Response:

  HTTP/1.1 201 Created
  Location: http://example.org/a-link-resource

This is definitely an edge case and I'm not sure if this is somewhere we
want to go at all, but such responses should not be ruled out (which also
speaks to the uncacheable nature of the LINK and UNLINK).

- James



  HTTP/1.1


> Amos
>
>
>