I remember being asked in the previous interview, how do your interfaces achieve idempotence. At that time, I was stunned. What is idempotence? Why haven't I heard o(╥﹏╥)o, I search various information on the Internet, now I will sort it out.
What is idempotence?
That is, the results of one request or multiple requests initiated by the user for the same operation are consistent, and there will be no side effects due to multiple clicks.
For example:
In the payment scenario, after the order payment is successful, the network is abnormal when the result is returned. At this time, the money is deducted. The user clicks to pay again, and the payment is successful and the result is returned. You will find that the amount is deducted once more, and the flow of funds also produces two recording.
Design interface idempotence scheme
The idempotent design of interfaces in different scenarios is different. If it is only a single payment operation, we can create a unique ticketId (that is, a ticket), and the ticket can only be used once.
Scenario 1, a single payment interface, the specific steps are as follows:
1. Asynchronous request to create ticketId
2. Call the payment interface to pass in the ticketId
3. Query whether the operation has been performed according to the ticketId, if the operation has been performed, the result will be returned directly, and if the operation has not been performed, the payment will be continued and the result will be saved.
4. Return the result to the client
Scenario two, modify the status of the order after paying first, the specific implementation steps:
1. Query the payment status of the order (payment status: paid, unpaid)
2. If you have already paid, return the result directly.
3. If the payment status is not paid, call the payment and modify the order status
4. Return the result