1

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.

  • Use message queues and take the headache out of this? How and when the server resumes the unfinished operation should not be dependent on user action. That's asking for even more headaches. – Marjan Venema May 31 '14 at 9:50
1

The GET should be indepotent. If you're using it to change state, then you're abusing the REST call and your api would be considered poorly designed. You shouldn't use GET and some side effect to proceed.

  • The GET operation is "idempotent" even if it has to finish/cleanup the operation in the background. If you repeat the GET operation (without other intervening requests), it will see the resource in the same state; thus idempotence. The thing I'm not quite sure is whether it is considered "safe". – Lie Ryan May 31 '14 at 4:05
  • If you don't make the GET call it doesn't resume. You would be relying on side effect behavior for the resume and IMHO that is a poor way to design it. – jmq May 31 '14 at 4:07
  • not immediately resuming doesn't matter to the system, due to the nature of the business rule, the user wouldn't be able to do much on the system without first resolving outstanding resources that is in intermediate states first, and it's easy enough to write some cron to force continuing them if necessary (this is doubtful to be necessary). Also, the implicit question is: what should I do instead and why? – Lie Ryan May 31 '14 at 4:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.