Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt

[Darrel Miller <[e-mail]>]

Jan,


On Wed, Jan 15, 2014 at 4:35 PM, Jan Algermissen
<[e-mail]> wrote:
>
> Uuuh - POST means POST ("process this"). A link rel cannot re-specify that.
>
> The rel conveys information about the nature of a target resource. This helps the client to form an expection about the resource and interact with it if it is programmed to do so. Maybe the resource does not even support a POST.
>

So, you agree that the rel "conveys the nature of a target resource".
And httpbis says

"The POST method requests that the target resource process the
representation enclosed in the request according to the resource's own
specific semantics."

So, if we put those two together then we can determine that the rel
defines the nature of the target resource and the resource defines the
semantics of POST for interactions with that resource.  Hence, I'm
going to conclude that it is not a huge stretch to say that you can
use link relations to define the semantics of a POST.

>>
>> If that concerns you then do you have suggestions on how the these
>> link relations should work:
>>
>> rel=payment        https://web-payments.org/specs/source/payment-links/
>
> You are loosing me here ... "payment" already exists in <http://tools.ietf.org/html/rfc5988#section-6.3>. And why is that spec not defining URI template variables and references the URI Template draft? <http://tools.ietf.org/html/rfc6570>
>

Yes rel="payment" does exist already and as far as I know no-one
defined what it really did, or how to use it, so no-one used it.
Someone now is actually trying to define some real semantics for it so
that it can actually be useful.


>
>> rel=hub
>> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
>
> The target 'is a hub' - what else do I need to know?
>

Where in the HTTP spec does it tell me what are the consequences of
doing a POST to link with rel="hub"?  If that information shouldn't be
in the link relation specification, where should it be?


>> rel=oauth2-token http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
>
> target is a resource where I can obtain an oauth2 token
>

How do you get a token?  By doing a GET? a POST?  Where should this be
documented?


>>
>> As far as I understand it, all of these have an associated meaning to
>> a POST request.
>
> Which is simpl not possible - you cannot override HTTP and still be 'within the system'. If you associate meaning with POST, you are defining an application protocol on top of HTTP.
>

But we are not redefining the meaning of POST.  Httpbis _explicitly_
says the meaning of POST is defined by the target resource and the rel
tells me that kind of resource that target resource is.


>>  Curiously, that meaning is not described in the rel
>> relation registration, but in the specification that describes the
>> protocol that uses the link relation.
>
> Which you can, if you mark it as a 'hint' or 'example' - just do not trick the client into making assumptions that REST deliberately wants the client *not* to make.
>

Let me quote from Roy's famous "REST APIs must be hypertext driven" blog post.

"The only types that are significant to a client are the current
representation’s media type and standardized relation names."

Let me re-phrase that to make my point.  Standard relation names can
be significant to the client.  I.e. In the same way we know from the
content-Type text/html that a tag called <form> can cause the user
agent to generate a POST request with a body
application/x-www-form-urlencoded we can use "Standardized relation
names" to tell the client how to generate POST requests with specific
media types.   Or is your assertion web browsers are making a non
RESTful assumption?


> The most interesting thing about all this is, IMHO, that you frankly do not need to know, because the method to use is usually sraight forward given the context. I mean, what method would you use for obtaining an oauth2 token?

So, are you asserting is that it is straightforward to know that you
must do a POST with application/x-www-form-urlencoded and a subset of
the following parameters:
grant_type,code,redirect_uri,username,password,scope.  And don't
forget each of those parameters have certain constraints defined by
the OAuth framework.

I apologize if any of this comes across as aggressive, I have tried to
filter out how annoyed I am, but may have failed.  I completely
respect your opinion.  I don't agree with it, but I hope we can work
towards a common ground.


Darrel