> > >----- Original Message ----- >From: "Jim Meyering" <[email protected]> >To: "Ori Liel" <[email protected]> >Cc: [email protected], [email protected], [email protected], >[email protected], "Einav Cohen" <[email protected]>, "Roy Golan" ><[email protected]>, "Michael Kublin" <[email protected]> >Sent: Wednesday, April 11, 2012 1:00:47 PM >Subject: Re: Hot-plug of disks and nics > >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".
#2 it is then. Thanks Jim, Eoghan _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
