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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhevm-api