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}/attach Pros: ---- * Less RESTful Cons: ----- * Consistent with other flows * Does not have the drawback of the additional business-logic described above Opinions? Thanks, Ori.