How to deal with the fact that the client does not know about the server state change due to a timeout?

Question

PHP

There is some api that mobile clients use.
Let's say the client has a bad connection, he makes a request to the api method, the server processes the request and gives a response.
At this moment, the client's connection has deteriorated and the request ends with a timeout error - it does not know about the change in the server state (let's say it does something if the request is successful).
How to solve the problem? Acknowledgment of receipt by the client?

Answer 1

When designing an API, it is necessary to ensure that all state-changing methods on the server are safe to be called again.
This can be done in essentially 2 ways, depending on the data being changed and the business logic.
1) When posting comments, for example, you can stupidly check on the server that the last comment from this user does not match the new one.
2) It is more universal - to do everything in 2 steps: with the first request we send what needs to be done, we receive in response a certain request id. With the 2nd request, we pass this id confirming that the request needs to be executed.

Answer 2

Another option is to consider the possibility of asynchronous execution of operations on the server. It is necessary to organize two or three methods in the API. The first method starts the process of changing the state (with validation of the current state and the possibility of changing it) and does not require the return of a result. The second method (optional) returns the progress of the server state change. The third - returns the result - the current state of the server. In this case, even if one of the requests does not receive a response, the client can repeat the request.

Answer 3

If there is no response from the server, then consider the operation failed and try all over again.

Answer 4

The client generates a transaction UUID and sends it to the server.
Let's say it took a long time and the client grabbed the 500th. In this case, the client requests (a separate API method) the status of the transaction (it knows its UUID). If it gets "everything is OK" - everything is OK)). If error: Requests cancellation of its transaction. If the 500th - tries to cancel the transaction, executing requests with an exponential delay, until it receives a response: yes, we canceled your transaction.