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

[Jan Algermissen <[e-mail]>]

On 15.01.2014, at 21:58, Darrel Miller <[e-mail]> wrote:

> Mike,
> 
> How do you feel about a link relation that says, if you do POST, it
> means this ...

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. 

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


> rel=hub
> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html

The target 'is a hub' - what else do I 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

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

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

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? 

>  This separation concerns me
> because we could end up with a situation where different protocols
> assign different interaction semantics to the same link relation.

HTTP is for the interaction semantics, link rels can only express the nature of a resource. They cannot constrain the server.

Jan


> 
> Darrel
> 
> 
> 
> On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <[e-mail]> wrote:
>> My advice is to *not* attempt to constrain how the client or server behaves
>> when using the link relation (e.g. "client SHOULD use POST to ....", etc.).
>> 
>> Instead just define the link relation's meaning and let clients and servers
>> use that shared meaning to do whatever they want with it.
>> 
>> 
>> 
>> 
>> 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 11:45 AM, Jan Algermissen
>> <[e-mail]> wrote:
>>> 
>>> 
>>> On 15.01.2014, at 16:59, Erlend Hamnaberg <[e-mail]> wrote:
>>> 
>>>> 
>>>> My use case has been a schedule for a conference.
>>>> 
>>>> The program is built over time, but once it is done, I want to publish
>>>> it.
>>> 
>>> If publishing is done by the same server, I'd change a property of the
>>> program to tell the server that it should publish.
>>> 
>>> When on a nother server, I'd try to POST the program's representation,
>>> implicitly creating a new publishing job. That job will have a URI which I
>>> would use to observer the state of the job.
>>> 
>>> Having "publish" point to the publishing system might make sense, in that
>>> sense "publish" would identoty a "resource providing publishing services".
>>> 
>>> I'd ovoid to POST the URI to the publishing service if possible, because
>>> it reduces simpicity IMHO, because the publishing system will need to go and
>>> GET the resuorec to be published which feels unnatural to me.
>>> 
>>> How does that resonate with you?
>>> 
>>> Jan
>>> 
>>>> 
>>>> I could, of course, go through each session and publish it directly.
>>>> Each publishing step is then a state change for each session.
>>>> However, for a user interface can become cumbersome.
>>>> 
>>>> However, If I decide to model this as two separate URIs,
>>>> I may need a different mechanism.
>>>> 
>>>> Not sure I am able to explain this appropriately.
>>>> 
>>>> Erlend
>>> 
>>> _______________________________________________
>>> apps-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
>> 
>> 
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss