Re: Extend describing operations

Hi Tomasz

I think your approach is not very restful. I'd start with revamping this 
API:
POST /blog - create a blog entry in a draft state
PUT /blog/{id} - update the blog with a published state
where the state would be yet another property of the post itself.

Alternative for those above would be to have two separate "views" of blog 
collection:
- one for drafts, i.e. /blog/draft
- one for puhlished one,s i.e. /blog/public
POSTing and PUTting would be available options for those.

It would be also more approriate (in my opinion) to allow client to put 
existing blog directly to either of the states with PUT - if the client is 
instructed on how to build a valid Uri.
HTTP spec allows PUT to create a resource if the Uri is known.

As an ultimate solution I'd ... use the hypermedia controls like next/prev 
to transition between resource states.:
1. POST /blog - create a new blog with a system's default state (draft) -> 
Location: /blog/{id}
2. GET /blog/{id} - get's the blog post with additional link hydra:next 
pointing to an operation which can be used to move the blog post to another 
state
3. POST/PUT {link from the hydra:next} - move the resource to another state

This way you could implement virtually every workflow that you could imagine 
with sticking only to those options that HTTP gives (GET/PUT/POST/DELETE 
etc.)
This way you will also limit yourself to already existing operations like 
CreateResource etc.

Best

Karol

-----Original message----- 
From: Tomasz Pluskiewicz
Sent: Sunday, March 13, 2016 4:50 PM
To: public-hydra@w3.org
Subject: Extend describing operations

Hi

I've been thinking about this for some time. Consider a blogging
platform, where I can POST a blog post

HTTP/1.1 POST /blog

{ "title": "My blog post", "text": "some markdown maybe"  }

But instead of getting published immediately, it could create a draft
at, say /drafts/my-blog-post.

Now how would I use Hydra to model an operation, which publishes the
draft? I would think of a POST operation like

HTTP/1.1 POST /blog/published

{ "@id": "/drafts/my-blog-post" }

Unfortunately I don't see how that would be possible. This raises a
number of questions:

1. Should it be possible to define complete or partial body of an
operation in addition to the "expects" property? I'm thinking

{
   "operation": [
     "expects": "BlogPost",
     "body": {
       "title": "New blog post"
     }
   ]
}

If the "expects" was absent, the "body" would be the complete request to
be sent by the client. Otherwise it could serve as an initial
representation to create the UI/form.

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" }
   ]
}

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

Best,
Tom

Received on Sunday, 13 March 2016 18:36:58 UTC