The idempotent nature of the RESTful API Toolbox (TODO)

Turn

There's a rather good explanation, dot I
Idempotent is the intrinsic nature of an operation, or we can implement all types of operations as idempotent. Some operations are inherently idempotent, such as taking data operations, copying operations, I perform countless fetch data operations, or copy operations, and the result is the same as executing it once. Some operations are not idempotent, such as delete operations, transfer operations. When you delete the second time, the system may say that the resource is no longer in existence; when the transfer operation executes the second time, you will have to turn over the money more than once. Objectively, such operations cannot be idempotent in nature. If you want to simulate idempotent: that is, the customer can try to perform this operation more than once, we must first get the ID of this operation, and then, take this ID to retry, the server will recognize this operation, if this operation, to execute, return OK to the client, if not executed, really go to execute this request, Return OK to the customer again. This operation is essentially executed only once, but such a design allows the client to retry multiple times, seemingly as a idempotent operation.

The basic idea of how to implement a idempotent operation is to get a transaction ID and use this ID to record whether the operation has been executed. Each time the client tries to take the money with this ID, the server will know whether the transaction has been executed.
My question is, when will the server be able to erase these transaction ID data? or keep it? It seems to me that there is no point in keeping this data. One possible solution is to send an additional request to delete the corresponding transaction ID when the client knows that its money-fetching operation has been executed successfully. While the delete operation is idempotent, the client can re-try until it is deleted. How the distributed transaction is done. TODO: Is there any other way to get the money out of a idempotent operation? TODO: Asynchronous Way. First to submit the job to get the money, and then you can try getting the job, but this job also need a token to mark, a bit similar. What are the benefits of idempotent. The primary solution to the power-on-money-fetching operation is to avoid the erroneous execution of the money-fetching operation without using distributed transactions. But the big context of the problem is that the network is unstable. If the network is an ideal situation completely stable, then there is no need for distributed transactions or idempotent, because I can execute each request correctly and get results. Todo

Good info:
https://mathieu.fenniak.net/idempotent-web-apis-what-benefit-do-i-get/
http://www.quora.com/ What-are-the-benefits-of-an-idempotent-api
https://www.safaribooksonline.com/library/view/ restful-web-services/9780596809140/ch01s04.html
Http://www.infoq.com/news/2013/04/idempotent