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