Re: Extend describing operations

Hi Tomasz,

Am 14.03.2016 um 12:28 schrieb Tomasz Pluskiewicz:
> Guys,
> 
> I'm glad you responded but your replies were sort of beside the point :)
> 
>> - PUT /blog/published/whatever
>>
> 
> That's what I was thinking. The client the blog post in the last request. How do we describe that with Hydra. As an operation or as a link?

With Hydra alone it is impossible to describe expected request bodies
with defined values.

The PUT must be an operation. How could it be a link?

> 
> I think that Hydra is missing an important piece here. 

+1

> We can define operations on self, and linking to other resource but it should be possible to describe operations on linked resources. 

You *can* link to any related collection resource with a
hydra:collection and have operations on its hydra:Collection value.

If you go that route, you still can't describe expected values.
For such purposes I conflate schema:PropertyValueSpecification with
hydra:SupportedProperty, but as of today one cannot expect a Hydra
compliant client to use that :-(

{
  "@context":
  {
    "@vocab": "http://example.com",
    "schema": "http://schema.org/"
  },
  "@type": "BlogPost",
  "@id": "/drafts/my-blog-post",
  "title": "My blog post",
  "text": "some markdown maybe",
  "hydra:collection":
  {
    "@id": "/blog/published",
    "hydra:manages":
    {
      "hydra:property": "publishedBlog",
      "hydra:subject": "/drafts/my-blog-post"
    },
    "hydra:operation":
    {
      "hydra:method": "POST",
      "hydra:expects":
      {
        "@type": "BlogPost",
        "hydra:supportedProperty": [
        {
          "@type": [
           "schema:PropertyValueSpecification",
           "hydra:SupportedProperty"
          ],
          "hydra:property": "@id",
          "schema:defaultValue": "/drafts/my-blog-post"
        }]
      }
    }
  }
}

To follow the partial update suggestion of rfc-7231 to have "a
separately identified resource with state that overlaps a portion of the
larger resource", one could have an embedded blogStatus resource and
give it a URI like "/drafts/my-blog-post/status" with a PUT.

But again, with Hydra alone we cannot say which value the PUT accepts
currently. With schema:PropertyValueSpecification, we can at least say
that we expect "Published" as default value.

{
  "@context":
  {
    "@vocab": "http://example.com/",
    "schema": "http://schema.org/",
    "status":{"@type": "@vocab"},
    "schema:defaultValue":{"@type": "@vocab"}
  },
  "@type": "BlogPost",
  "@id": "/drafts/my-blog-post",
  "title": "My blog post",
  "text": "some markdown maybe",
  "blogStatus":
  {
    "@id": "/drafts/my-blog-post/status",
    "@type": "BlogStatus",
    "status": "Draft",
    "hydra:operation":
    {
      "hydra:method": "PUT",
      "hydra:expects":
      {
        "@type": "BlogPost",
        "hydra:supportedProperty": [
        {
          "@type": [
           "schema:PropertyValueSpecification",
           "hydra:SupportedProperty"
          ],
          "hydra:property": "status",
          "schema:defaultValue": "Published"
        }]
      }
    }
  }
}

> And I don't mean supportedClass/supportedProperty/supportedOperation path. This is still operation on self, but the self is the linked resource.

I do not understand. Your BlogPost could certainly have an operation on
the self URL /drafts/my-blog-post. But what do you mean by "the self is
the linked resource"?

Best regards,
Dietrich

Received on Sunday, 3 April 2016 16:58:38 UTC