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

[mike amundsen <[e-mail]>]

PMFJI...

<snip>
>> 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?
</snip>

The rei is NOT the affordance. It does not tell you how to do anything.

for HTML/HTTP this is one way to know "how":
<form method="get" href="..." class="oauth2-token">...</form>
AND/OR
<form method="post" href="..." class="oauth2-token">...</form>

over CoAP, MQTT, using Cj, Siren, etc. the details will vary but what is
consistent is that you get hits "how" information via the affordance
itself. IMO, do not need to load network semantics into a link rel value.
and, as i mentioned earlier in this thread, i think doing so is a bad idea.

<snip>
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.
</snip>

yes. IF you put those two together. that doesn't mean you MUST. that
doesn't mean putting them together as part of the link rel valu
registration is the best (or only) way to do it. that doesn't even mean it
is a good idea. that just means IF.

<snip>
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.
</snip>

not sure what you think you are "stretching" here. the HTTP spec? the
LinkRel registry? logic? credibility? ;D

finally, just because you CAN doesn't mean you SHOULD.

Cheers.





mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


On Wed, Jan 15, 2014 at 5:18 PM, Darrel Miller <[e-mail]>wrote:

> 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
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>