[occi-wg] Modeling proposal for ReST/Cloud based commands.
bburke at redhat.com
Wed Oct 14 19:35:30 CDT 2009
Sam Johnston wrote:
> 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:
> but the following "feels funky":
> I much prefer:
> POST http://example.com/disk01;resize
> 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).
Actually, i should have probably said this to Adrian:
Then a GET of /robots/333/deaths might returna feed of what the
different deaths were and when.
As for pubsubhubbub, I don't like the reliance on Etag semantics for
polling. Feels like you're tunneling a protocol. I'd much prefer to
send a link back to the client telling it how it can get further (new)
data. I also don't like the reliance on Atom. Atom is fine for text
formats, not great for others. So, what I'm going to do is turn Atom's
(and messaging metadata in general, Atom's metadata isn't something
revolutionary) Into a set of headers and use multipart to send batches.
IMO, multipart is much more appropriate.
JBoss, a division of Red Hat
More information about the occi-wg