Ori Liel wrote:
On the subject of activate/deactivate disks and nics
("hot-plug"), I'd
like to hear opinions about the correct modelling. I see two possible
options (I will use disks as an example, but the chosen modelling
should be the same for nics and disks).
Option 1 - update:
=================
PUT
.../api/vms/{vm:id}/disks/{disk:id}
<disk>
<activated>true</activated>
</disk>
Pros:
-----
* RESTful, no need for new action
Cons:
-----
* Inconsistent with other flows. We do not normally update status
fields to perform actions. For example to run a VM, we do not update
it's status to 'activated', we run an action (start).
* Enables user to update disk properties AND activate/deactivate in
the same operation. Updating certain disk properties is forbidden
while the VM is up, but activating/deactivating the disk is allowed
always. This requires business-logic in REST-API: if the user
activates the disk and changes properties on it - REST-API must first
change the properties and then activate the disk (if disk is activated
first, update properties will fail). If, on the other hand, the user
*deactivates* the disk and changes properties on it - REST-API must
first deactivate the disk and then change the properties (changing
properties while disk is still active will fail). This bug-prone logic
is only necessary because when activate/deactivate is merged with
update.
Option 2 - action
=================
.../api/vms/{vm:id}/disks/{disk:id}/[activate]
[Con]:
----
* Less RESTful
[Pros]:
-----
* Consistent with other flows
* Does not have the drawback of the additional business-logic described above
I too prefer #2.
IMHO, we need not be slaves to consistency or RESTfulness, but here,
consistency wins hands down when strict conformance to REST guidelines
evokes a paragraph worth of "Cons".