I have a RESTful API, one of the resource has a state that is determined collectively by multiple servers, not all of them belong to us. One of the operation on this resource will have to modify the state of multiple servers. The client sends a POST request to do this operation to our API server and our API server sends requests to the other servers to fulfil the request.

Due to the nature of the whole operations, not all of the operation can be done in a single transaction. The APIs for the participating servers mostly do not support 2-phase commit, but most do have some idempotence guarantee, although not all of them are RPCish rather than RESTful. If any error happens during this operation, the resource is left on an intermediate state, but the server should be able to repeat the operations from the point it has left off to fix the resource’s state.

Would it be a bad idea or would it conflict with REST principles if the server transparently resumes unfinished operations the next time the client reloads the state of the request (with a GET) rather than requiring the client to discover the resource is in an intermediate state and send another request to fix the situation before continuing anything else.

One one hand, GET is supposed to be a safe operation, but on the other hand, letting GET resolve the situation simplifies the client as it doesn’t have to deal with this situation.

Note that the users also interacts with the other participating servers directly (i.e. not just through our client) so they may see some of the effects of the operations if a resource is left in an intermediate state.