trivia: REST and virtual machines are not compatible .

There is a long-standing dispute in which I participated several times, and which so far hangs unresolved. I bring here the existing argument, I will listen with interest to the comments and additional arguments.

So,
Thesis 1: REST is good, * -RPC (for example, XML-RPC, JSON-RPC) is bad.
Thesis 2: Because REST is good, it needs to be used to manage virtual machines (particularly in the cloud).
')
At first glance, it is. For example, if we want to change the attribute (say, the attribute “boot disk”) for a virtual machine, then we write:

 PUT ... / vm333 / disk1 / bootable
 enable = true
 PUT ... / vm333 / disk1 / bootable
 enable = false

Or even like this:

 POST / vm / 333 / disk1 / bootable
 DELETE / vm333 / disk1 / bootable

If we want to create a disk, we say POST / vm333 / disk2 and pass attributes (like size or storage).

However, this is good only up to the moment when our infrastructure resembles a database record.

And now a simple question: how will the virtual machine reload command look like in REST? After all, the state of the machine does not change, as was running, and remains. Obviously, the reboot is not an idempotent call, that is, we must say POST. But 'POST what and where?'. Note that even shutdown / start is quite within the POST of the power-state. But here the reboot - which violates the logic of the “immanence” of the state of the object in the database and leads us to the cruel imperative world - alas, does not fit. Similar problems will occur during the 'install' operation (launch of the OS installation).
The reason here is much deeper than just "not very good at it." Sorry for the word "ontology", but this reason is ontological.

The essence of the problem

Objects in the cloud (and indeed, in the server management farm) are not lines in the database. They live their lives, and what is visible in our database (to which we are trying to attach a REST interface) is only a display of this life.

Some of the attributes in the database are authoritative values. For example, if we said that this machine is called 'foobar', then it is called that. And the opinion of blacks does not give the sheriff pleasure. However, for example, consider the 'running' state. After all, this is not an “attribute” of a database for managing a virtual machine. This is her, her PERSONAL state. As she wants, so be it. If you want to crash at the start, you will not be able to do it by writing the power-state attribute to the value of 'running' by any means. Similarly with many other questions: we can say “do it yourself 32 MB of memory”, but the virtual machine can look at the memory occupied by the 48 MB kernel and say “thank you, don't need it” - and stop at 64 MB. We recorded the attribute "32 mb", and there "64 mb". And the most terrible thing is that it was not a situation “could not deliver”, a failure in the transaction. It "did what it could, it did." It was 128MB, they said to make 32, it became 64. Moreover, with a delay - first 96MB, then 82, and only in 20 minutes - 64. Moreover, if we tense up and force the car (or rather, the car "will not think a head" ), then instead of 32MB we get power-state = crashed. Instead of the expected 32Mb. Nonsense. Not a database, but some kind of pornography.

The reason is that our database to which we write is not a database. These are our authoritative values ​​(about which a virtual machine doesn’t have a dream, like its name and number - and here it is a real database without the slightest doubt), these are our limitations for the machine (which the machine can try to get around, but it will not work, too ) and these are our wishes , which the machine may try to fulfill, but it may not work or may not turn out completely .

Thus, we see a contradiction in the essence of the relationship between REST-ideology of relations with an obedient database and the real world.

RPC will save the world?

In this case, the imperative approach looks much more reasonable - the use of any kind of RPC, in which we “call” remote (imperative) functions and pass arguments to them.

In this case, “they began to change one thing, it turned out another” looks much more logical. Especially if instead of vm.set_memory () we will do vm.send_desired_mem (). The first team can make nonsense, the second - never. They said to pass the number passed. And what will be further depends on VM. In this case, we solve the ontological problem - we recognize the right to independence of the managed objects (where we can - we allow / prohibit, where we can not - we fix the actual state).

But RPC rightly scold, because it is heavy, inconvenient and makes you think about the subject area, instead of comfortable contemplation of relations in the database.

In this place the beautiful story ends and the word is given to the commentator .