RE: Extend describing operations

On 6 Apr 2016 at 21:20, Asbjørn Ulsberg wrote:
> 2016-04-05 22:24 GMT+02:00 Markus Lanthaler <markus.lanthaler@gmx.net>:
> 
>> On 13 Mrz 2016 at 16:50, Tomasz Pluskiewicz wrote:
>> 
>>> 2. Should it be possible to have an operation not on self but on another
>>> resource. This is what I could write to describe the publish operation
>>> above:
>>> 
>>> {
>>>    "operation": [
>>>      "@type": "PublishOperation",
>>>      "url": "/blog/published",
>>>      "body": { "@id": "/drafts/my-blog-post" }
>>>    ]
>>> }
>> 
>> Yes, we should make that possible.
> 
> I agree.
> 
>> We just need to find a way to relate the resource to the operation then...
>> the simplest solution would be to leverage schema.org/action for that.
> 
> Are you sure? https://schema.org/action:
> 
>> The movement the muscle generates.
> 
> ;-)
> 
> I guess you didn't copy + paste that URL, because
> https://schema.org/Action looks more like what we're after:

No, I didn't. Sorry. What I actually meant was https://schema.org/potentialAction


 
>> An action performed by a direct agent and indirect participants upon a
>> direct object.
> 
> :-)
> 
>>> I'm feeling kind of like the "/blog/published" resource should be a link
>>> with it's own operation. I'm still not sure how what to do about the
>>> predefined "body".
>> 
>> The simplest approach would be to add a "status" property to the blog
>> post.
> 
> Yes, and then PATCH it? Or expose it as a resource and PUT on it. Agree?

Either is fine. I think for most resources, requiring the client to replace the resource, i.e., sending all other properties as well, would be fine too.



>> [1] https://tools.ietf.org/html/draft-snell-link-method-12
> 
> Interesting. This updates the semantics of the methods already defined
> in RFC 2068, afaict?

I would say it properly defines them. I would argue they have been kind of experimental methods till now but agree that it sounds weird given that even RFC2068 was written almost 20 years ago :-)



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 6 April 2016 19:42:20 UTC