Re: Link Relations

On Fri, Nov 8, 2013 at 1:31 AM, Jan Algermissen
<[email protected]> wrote:
> Hi Mike,
>
> On 08.11.2013, at 02:08, mike amundsen <[email protected]> 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
application?

Cheers,
M