Loading ...
Sorry, an error occurred while loading the content.

19547Re: [rest-discuss] Link Relations

Expand Messages
  • Mike Kelly
    Nov 7 11:58 PM
    • 0 Attachment
      On Fri, Nov 8, 2013 at 1:31 AM, Jan Algermissen
      <jan.algermissen@...> wrote:
      > Hi Mike,
      > On 08.11.2013, at 02:08, mike amundsen <mamund@...> wrote:
      >> not sure i understand the Q, but i'll offer this:
      >> rel="http://example.com/rels/publisher" describes the relationship between the source and the target.
      > I like to try to emphasize what the target is *to the source* with the goal that the application-level effect of the HTTP methods falls into place.
      > This IMO helps a great deal with avoiding to layer specialized application protocols on top of HTTP (which already is the application protocol).
      > IOW, it helps prevent redefinitions of the meaning of HTTP methods. POST means POST, it cannot mean 'publish the source resource'. DELETE means DELETE, it cannot mean 'unpublish the the source resource'.

      Well, those methods have a general meaning within the uniform
      interface of HTTP whose purpose is to add to the self-descriptiveness
      of messages and, in doing so, to afford intermediation across the
      system (e.g. web caching). The HTTP method definitions attribute
      meaning designed for this purpose (e.g. establishing safety,
      idempotency, cacheability, etc).

      Provided the link relations are not in conflict with the HTTP
      definitions, and are merely qualifying the details of methods within
      the context of a given transition, then it is wrong to think about
      that in terms of "redefinition". It's qualification.

      In practice, it's much easier for consuming parties if your
      documentation is specific by providing an explicit description of the
      meaning and structure of the various requests possible over a given
      link. Leaving your documentation so abstract that the reader is left
      with the task of inferring every part of each possible request does
      not seem like a very pragmatic approach for custom link relations (but
      may be more appropriate for standardised link relations).

      > If you find yourself in a situation that you absolutely must tell the client developer this, rephrase the hypermedia semantic (here: the link rel spec).
      > There is nothing to say againts hints regarding the intended 'canonical' use case but I can always only be a hint. AtomPub is an example, where the spec tells us so much about the interactions between client and server that it looks like a protocol when it is actually only hints about a canonical application flow. Focussing on resource semantics would have been much nicer, IMHO.
      > One simply cannot constrain HTTP servers that way and still have REST.

      The importance of HTTP methods from a REST point of view is that they
      create **some** visibility of the client server interactions, so that
      the messages can be understood to _a certain extent_ by
      intermediaries. Provided that visibility is not impacted (i.e. a link
      rel's qualification of a method doesn't _conflict_ with HTTP's) then
      how does this have any bearing on the "RESTfulness" of the

    • Show all 25 messages in this topic