Providing parameters to a RESTful POST request that requires confirmation

Question

I am developing a REST service, and one of my server-side operations manipulates the DB in a way that may take a while, but once the operation has started, the DB cannot be recovered (this is a constraint that comes from the system we are using on our server. I might be able to change it in later versions, but for now we are stuck with this constraint). The result is that I need an "ok/cancel" dialog with a warning, before allowing the operation to run.

At first I wanted to put the logic of creating the dialog on the client-side, but that seems to violate HATEOAS (for example, if I do change the framework on my server side, the dialog won't be needed, but I won't want to change the client if my API stays the same). My next solution was returning a response with the warning, and an ok that links to a different POST operation, but I am unsure on when to send my parameters. Do I send the parameters in the first POST? If so, how do they get to the second POST (without holding application state, of course)? Sending the parameters only to the second POST isn't an option since only HATEOAS will determine if the second one is needed.

I have found a similar question here: REST, HTTP DELETE and parameters But this has 2 problems:

1. It doesn't solve our problem (because he only adds a parameter on the second try, but I need to carry my parameters with me from the first).
2. DELETE has to conform to "Uniform Interface". He does make a valid point that not all clients necessarily need confirmation, but putting the whole dialog in UI brings me back to our problem of what happens if I improve my server-side app.

I would be happy to hear your thoughts on the matter.

P.S: This is my first post on stackoverflow.com (after years of using it to find answers for questions that were asked before me), so please forgive me if the format of the question isn't quite right (you are welcome to correct me, of course).

Answer 1

One of your server-side operations needs confirmation before it can be executed. The way I see it this means two different calls, which may for example mean to first check that you need the confirmation and then doing the actual action.

For example, you may request that the client first does a GET to see if a confirmation is required and retrieve the message to display, then do the actual POST with the action. If you don't have a GET request first, the POST may return a 4xx (maybe 412?) error.

BUT, keep in mind that no matter what you do, you need cooperation from the client. Even if the server does receive a GET request, the client may receive the response, not show the confirmation and doing the post anyway, it's not something you can solve 100% server side.