<method name="Upgrade"></method>
<method name="Rollback"></method>
For these sorts of operations, one often puts in an in options argument,
of type a{sv} ... to future proof. For example:
rpm-ostree rollback [OPTION...] - Revert to the previously booted tree
-r, --reboot Initiate a reboot after rollback is prepared
rpm-ostree upgrade [OPTION...] - Perform a system upgrade
--os=OSNAME Operate on provided OSNAME
-r, --reboot Initiate a reboot after an upgrade is prepared
--allow-downgrade Permit deployment of chronologically older trees
--check-diff Check for upgrades and print package diff only
How are you planning on implementing these via the API? Some of them
seem to fit naturaly in such an options argument, whereas others are
probably separate method calls (eg: --check-diff), or implemented in the
client (eg: --reboot).