Re: FYI: LINK and UNLINK

Some specific answers,

On Tue, Nov 5, 2013 at 5:09 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
[snip]
> some feedback:
>
> - you may want to talk about what kind of processing of the link target
> happens, such as: is the server allowed or even required to check the
> target's existence (thus can LINK create "dangling" links?) If it does, an
> example would help (status code etc)
>

No specific processing steps are required by the server. It MAY check
to see if the target exists but is not required to do so (and, in some
cases, such checks could be impractical or impossible).

> - clarify whether an anchor parameter should either be ignored or be an
> error
>

You mean fragment identifier, correct? If so, the answer is: No,
fragment identifiers MUST NOT be ignored. The target URL ought to be
considered exactly as given (with proper consideration given to
relative URL's, of course). For instance, the following would create
two separate links:

  LINK /my/resource HTTP/1.1
  Host: example.org
  Link: </other/resource#foo>; rel="baz"
  Link: </other/resource#bar>; rel="baz"

> - you and I know that success could be 200 or 204, but if you don't have it
> at least in the examples, at least some people will be confused (and argue
> whether it should be 201 :-)
>

201 implies that a resource is being created... which might not
actually be the case. I could take some time to draw that out in the
draft, if necessary.

> - is it an error to try to remove a link that doesn't exist? What if I try
> to UNLINK one existing and one non-existing one?
>

Nope, it's not. The UNLINK request is idempotent and always has the
same result... If I send an UNLINK that identifies one existing link
and one non-existing link, the result in the end is the same...
neither link between the two resources will exist (which is the exact
intent of the request). The server would simply ignore the request to
unlink the non-existent link.

And no, there is no need to UNLINK before replacing/updating an existing LINK.

- James

> Best regards, Julian
>

Received on Wednesday, 6 November 2013 03:04:05 UTC