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

[Jan Algermissen <[e-mail]>]

On 15.01.2014, at 23:18, 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.

From the POV of the client POST means "process according to what you 'are'". And yes, the link rel leads the client to combine the POST with an expectation about the effect - manifested in the choice of resource (which is lead by the rel).

But I would not got further than that, let alone say "POSTing to a foo means X'.

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

How can a link relation spec say anything about what method a resource will support at any given point in time?

But still, what bothers me the most os that you simply do not *need to* say all this.

To me, doing so merely signals RPC-driven thinking (not saying *you* do not 'get it').


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

Hmm, but 'a resource where payment can be made' seems like fine semantics to me. I guess the original idea was somehow connected to "402 Payment Required" - if you find you need to pay for access, rel="payment" is how you find out where.

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

Isn't the nature of a pubsuhubbub hub just all you need to know?

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

How would you think you should get a token with an idempotent and safe GET? With a PUT? nah? DELETE?

Hence: POST.

> 
> 
>>> 
>>> 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

No, it says "process according to .. own semantics". Maybe another, last finding for httpbis?

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

Hmm, nice point. Will come back on that tomorrow.

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

Id id not say I liked OAuth2 or the link rel very much :-)  The stuff you mention above is surely something to be discovered at runtime.
[Set aside maybe the problem that security and discovery don't mix so well since a MITM could trick me in discovering malicious suff :-) I am still personally chewing on discovery and security. Should a 401 response tell a client where an authorization server is???]

> 
> I apologize if any of this comes across as aggressive

Nah - I like sticking to positions rather than giving up too fast. Yields much better analysis.

> , I have tried to
> filter out how annoyed I am, but may have failed.  I completely
> respect your opinion.  

Dito!

> I don't agree with it, but I hope we can work
> towards a common ground.
> 

I'll chew on that paragraph above. Not having a good answer yet.

Jan

> 
> Darrel
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss