"Edmonds, AndrewX" <andrewx.edmonds@intel.com> writes:
e.g. stop (GRACEFUL) or stop(KILL)
We did this initially but moved to separate stop (nowadays our destroy) and shutdown completely as they felt like conceptually different operations happening at different layers of abstraction. Perhaps this is an implementation distinction though.
Well won't the result of a POST to server/create utilise HATEOAS or something similar? The result should contain information pertaining to the state of the resultant action.
My point was that one should be able to request the end state expected from the create, and get an error if that's not possible, instead of a server in an unexpected state. (Example: two servers sharing a disk. I boot the first, and then create the second with the same disk specified, expecting it to be created but not running, so I can gracefully shut down the other before booting it. Alas I'm using Amazon, so my server is started automatically, the disk is mounted by two VMs simultaneously, and the filesystem is trashed. This stuff should be specified and deterministic to avoid gotchas.) Cheers, Chris.