Is rebooting a server idempotent or not?

Question

In his article RESTful Casuistry, Tim Bray claims that rebooting a server is not idempotent:

But I don’t buy it, and here’s why. If I want to update some fields in an existing resource, I’m inclined to think about PUT. But that doesn’t work because it’s supposed to be idempotent, and rebooting a server sure isn’t. Well, OK, do it with POST I guess; no biggie.

Yet in comments Mike Kelly states that it is:

The problem I see here is that ’switching’ to reboot does, infact, seem like an idempotent action - the idea being that a ‘rebooting’ state would actually be a graceful shutdown, to an off state, and back to an on state immediately. Once this rebooting state was initiated any further updates to the rebooting state would be idempotent:

PUT /vm/test-machine/power

{ ’state’: ‘rebooting’ }

The definition of idempotence is given in RFC 7231, § 4.2.2. ‘Idempotent Methods’:

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.

Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.

The intended effect in our situation is that the server has been rebooted. I think this will be the case after both a single or multiple reboot requests. So I am inclined to agree with Mike Kelly that rebooting a server is idempotent. But I don’t share his view that it is because subsequent reboot requests received during the rebooting phase have no effect; to me it is because subsequent reboot requests after the rebooting phase produce the same effect. Nor do I share his view that the PUT method should be used for this since the intended effect of the PUT method is to create or update the state of the target resource with the state defined by the representation enclosed in the request, reducing server reboot to a side effect.

Is rebooting a server idempotent or not?

Answer 1

The problem here is that Tim Bray doesn't explain why he thinks it's not idempotent. The concept of idempotency is somewhat subjective. When we call a PUT twice there are a number of things that aren't the same as when we call it once. For example, the server access logs will be different as well as other logging. There might be other side effects to the PUT call as well such as events that are generated. But we explicitly choose to ignore certain factors.

In a containerized, cloud-based solution (which was not really a thing in 2009), is restarting a container idempotent? Probably but if it's holding a local in-memory data that is not persisted anywhere, no, it's not. There are too many factors here to say it's always one or the other. Perhaps his point is that it's not, in general, the case that rebooting a server is idempotent. That doesn't mean it can't be, just that you can't assume it is.

Answer 2

After the server has rebooted, it isn't in state rebooting anymore, so another reboot action isn't really idempotent in the sense of leaving the resource in the desired state if it is already in that state.

One (admittedly contrived) solution would be to have a resource rebootCount that you'd change to cause a reboot. If the server has been booted 10 times, you PUT 11 into it to get it to reboot and into the "rebooted 11 times" state. If another request also puts 11 into that resource it's idempotent, it doesn't cause an additional reboot but leaves the server in that state.