In my view, backwards compatible DELETE semantics for a floating disk aren't that bad:
DELETE /vms/{vm:id}/disks/{disk:id}
=> Accept a <detach>true|false</detach> argument. => Defaults to "false" for compatibility.
This means that DELETE will by default really DELETE any non-floating disk. That is compatibility with today. For safety, implement this:
=> When deleting a disk that is floating, fail unless <force> is also set to "true". And always fail if one of the other VMs is running (obviously).
To attach a disk and make it float, use POST and you and Eoghan described.
To detach a disk, use DELETE with <detach>true</detach>.
To delete a non-attached, floating disks, use:
DELETE /disks/{disk:id}
To delete an attached, floating disk, use:
DELETE /vm/{vm:id}/disks/{disk:id} with <force>true</force>; OR DELETE /disks/{disk:id}
While keeping to the DELETE pattern for detach is attractive, the use of two separate flags (detach and force), plus the requirement to special-case deletion logic in the floating disk case, seems to outweigh the benefit. This scenario would seem to fit in with the critera we applied when choosing actions over standard verbs in the first place - i.e. a case where a standard verb leads to awkward, counter-intuitive or unnatural usage. In this case, the client-side logic to select the force flag and the error handling for an inadvertent DELETE-delete when a DELETE-detach was intended (409 status, I guess?), would seem to me to justify going the action route. Just my 2 cents ... Cheers, Eoghan