Hi Geert,

Interesting idea.

So for the sake of comparison, what we currently model as:

POST /hosts/123/install
Content-Type: application/xml
<action>
  <root_password>geronimo</root_password>
</action>

you're suggesting we change to:

POST /hosts/123/actions
Content-Type: application/xml
<action>
  <command>approve</command>
  <root_password>geronimo</root_password>
</action>

right?

How would you characterize the increased RESTfulness of the latter? Is it the use of a common target URI as opposed to a per-action URI (i.e. /hosts/123/actions as opposed to /hosts/123/install) that makes its seem less RPC-oriented in your view? I guess I'm not convinced that the latter is any less reminiscent of RPC than the former.

Now one advantage of the action-specific URI approach that we've taken is that the set of potential actions on a resource can be described nicely in the entity representation, in the form of a set of per-action links. Whereas in the alternate model, we would presumably have just a single action link in the representation, so we'd need to come up with a new way of representing the set of possible actions applicable to that resource.

Cheers,
Eoghan


On 13 September 2010 14:25, Geert Jansen <gjansen@redhat.com> wrote:
Hi guys,

i had a go at the latest snapshot (snapshot3). I must say it looks
really good and you guys made tons of progress.

One thing that caught my attention is the actions protocol. I understand
that the fundamental difficulty that you're trying to solve is
shoehorning an RPC concept into a RESTful API. I struggled with that as
well when i wrote my API, and I haven't come to an ideal solution
either. That said, i think actions can be solved in a more RESTful way
than they are done now. It would be by using an "actions" subcollection,
where you POST an "action" object. Something like:

 POST /hosts/123/actions
 Content-Type: text/xml

 <action>
  <command>approve</command>
 </action>

 201 CREATED

It's not fully RESTful because only POST would be defined. (In theory it
would be possible to complement this with a full set of verbs making
"actions" fully RESTful. The semantics of the collection would be a set
of actions that have been executed for a resource. New actions posted
are executed automatically. Old actions are kept for reference and can
be retrieved. Note that this is a theoretical discussion as there is no
such thing as a log of actions in RHEV. The only thing this proves is
that this approach "quasi" RESTful :)

There's also the advantage that you've now disentangled the namespace
for actions and subcollections, and that you removed the "empty POST"
mechanism which is a bit ugly in my view.

I'm not saying these are make or break, but in my feeling it's a bit
cleaner this way. Just my 2 cents.

Regards,
Geert
_______________________________________________
rhevm-api mailing list
rhevm-api@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhevm-api