[occi-wg] Modeling proposal for ReST/Cloud based commands.

Fri Oct 16 14:48:41 CDT 2009

Thanks for all the input, guys.  comments below:

On Wed, Oct 14, 2009 at 5:17 PM, Sam Johnston <samj at samj.net> wrote:

> Bill,
>
> Ironically Adrian wrote this post after being prompted by myself and Andy
> Edmonds from the OCCI-WG following criticism of exactly this approach. I
> definitely think links are a great way of satisfying the hypertext
> constraint (formerly known as HATEOAS) but I'm intrigued by what specific
> problems he has with this approach - e.g. "what could possibly go wrong"?
>
> In many (most?) cases the "actions" are not parametrised in which case the
> entity-body is empty, but the alternative, doing an empty POST to a
> parametrised (GET-style) URL, feels [very] wrong. While URLs should be
> considered opaque, I'm ok with using either semicolons or path segments
> ('/') to delineate actions:
>
> http://example.com/vm01;start
>
> but the following "feels funky":
>
> http://example.com/disk01;resize=20000
>
> I much prefer:
>
> POST http://example.com/disk01;resize
> size=20000
>
> So what we are currently doing for "actions" is a post/redirect/get
> pattern <http://en.wikipedia.org/wiki/Post/Redirect/Get> which I feel is
> quite elegant in that it allows us to handle more challenging realities such
> as asynchronous responses (e.g. returning HTTP 201 Accepted with a Location:
> header which can be monitored ala pubsubhubbub or polled).
>
> Adrian was talking about servers returning 409 Conflict but I don't have a
> problem with that either - if so the client knows it can try again later and
> doing anything else (like saving and replaying the request on the server
> side) doesn't seem right to me either as it's a form of server-side state.
>
PRG does use forms as a standard example, but whether the POST uses matrix,
form, or headers for the submission data, the PRG doesn't change
conceptually or implementation.  In other words, there is nothing compatible
or incompatible about PRG wrt this topic of matrix params or headers or
whatever.  That said, I think it is useful to surround the discussion with
the greater context, which is important.

I postulate that regardless of java, python, curl, (name whatever you like),
clients will be more efficient and capable on retrying transient failures if
they are not required to store entities along with their requests.  I'll
challenge anyone to write a test in any language showing parsing entities as
faster, more resilient to retries, or more scalable then 0-length requests
using matrix or headers for things like this=true or that=2000 :)

Log files are also useful when they can reveal context of requests; in this
case requestline is generally what you have to work with.  Imagine a system
that requires body logging on at all times to get whether something is true
or not ?!

At the end of the day, I argue that endpoints of simple state transitions,
namespace creation, etc. are great applications for alternatives to forms or
envelopes enclosing primitives, and by no means limit use of patterns like
PRG.  This isn't a golden hammer; I'll prefer json, xml, binary, form,
multipart and other entities for other contexts.

It's totally cool if this is too weird to endorse.  At any rate, alternate
patterns like this help us clarify our own priorities, and I hope this much
has been useful to y'all.  I certainly have more clarity based on your
feedback.  Thanks for that.

Cheers,
-Adrian

>
> Anyway it's good to see this all starting to coalesce - just need to sort
> out the nitty gritty details.
>
> Sam
>
>
> On Thu, Oct 15, 2009 at 1:43 AM, Bill Burke <bburke at redhat.com> wrote:
>
>>
>> Well, the more restful way of doing it would be:
>>
>> GET of /objects/robot/3333 returns:
>>
>> {"robot" :
>>    {"name" : "Mr. Roboto",
>>     "links" : [ {"rel" : "kill", "href" : "http://.../objects/robot/3333/kill",
>> "type" : "application/x-form-urlencoded}]
>>    }
>> }
>>
>> So, the idea is you get the representation of the robot, and the links
>> define what relationships are to the robot.  One of the relationships is
>> "kill".  You follow the link by posting to it:
>>
>> POST /objects/robot/333/kill
>>
>> death=slow
>>
>> GET of /objects/robot/333/kill might return:
>>
>> "This robot died a slow death"
>>
>> The thing is here that the URL patterns are irrelevant, the URLs are
>> opaque, you navigate to them by linking.
>>
>>
>> Adrian Cole wrote:
>>
>>> sorry.. the rendering is bad in firefox.
>>>
>>> Here's the matrix example:
>>>
>>> POST http://localhost:8080/objects/robot/action/kill;death=slow HTTP/1.1
>>>
>>> Here's the entity example (objects renamed from a real cloud api):
>>>
>>> POST http://localhost:8080/objects/robot/action HTTP/1.1
>>> Content-Length: 25
>>>
>>> {"kill":{"death":"slow"}}
>>>
>>>
>>> This is probably more high-level, but if it is rest to address resources
>>> as /path/to and operate them with POST, DELETE, etc, it may come naturally
>>> for some who are FSMs to offer state transition commands.  In this case,
>>> simple command patterns come in handy and are currently in use in compute
>>> clouds, for example.
>>>
>>> I hope this background helps.  If the topic doesn't fit the list, let me
>>> know.
>>> Cheers,
>>> -Adrian
>>>
>>>
>>> On Wed, Oct 14, 2009 at 2:55 PM, Bill Burke <bburke at redhat.com <mailto:
>>> bburke at redhat.com>> wrote:
>>>
>>>
>>>    REST is not an RPC model...Or maybe I'm misinterpreting you.  Also,
>>>    the code examples in your blog are cut off.
>>>
>>>
>>>    Adrian Cole wrote:
>>>
>>>        Hi, all.
>>>
>>>        I'd like your opinion on modeling ReST commands on the server
>>>        side.  I've placed a suggestion for thought on my blog [1].
>>>         Please let me know what you think.  The basic idea is to prefer
>>>        not using entities on commands as it makes retry logic easier.
>>>         In such case, we can use Matrix Params instead.
>>>
>>>        Cheers.
>>>        -Adrian
>>>        founder jclouds
>>>
>>>        [1]
>>>
>>> http://anyweight.blogspot.com/2009/10/rest-be-nice-no-entities-please.html
>>>
>>>
>>> http://www.reddit.com/r/programming/comments/9u2ic/rest_be_nice_no_entities_please/
>>>        http://digg.com/programming/ReST_be_nice_no_entities_please
>>>
>>>
>>>    --    Bill Burke
>>>    JBoss, a division of Red Hat
>>>    http://bill.burkecentral.com
>>>
>>>
>>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091016/f589aed5/attachment.html 