Sam Johnston 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:
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).
Actually, i should have probably said this to Adrian: POST /robots/333/deaths death=slow 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. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com