Recently, I have nothing to do, and I like to listen to the big guys. They said that a topic of the interview, interface idempotence problem, was also encountered in their own work, and there was no good way to solve it before. After hearing a good way, I decided to write it down.
What is idempotent, the online statement is very detailed, my understanding is because of the repeated call for the increase, deletion and change in CURD, query originally follows the idempotent principle, reflected in the interface, is due to network delay, user operation caused by multiple access to an excuse, resulting in multiple calls.
Big guy’s more classic: the user for the same operation initiated by a request or multiple requests the results are consistent, there will be no side effects due to multiple clicks.
The solution
1. Take simple form validation
This.$store.com MIT (‘ setSerialNO, new Date (). The getTime ());
Each time the front end calls the back-end interface, it will carry a timestamp SerialNO, which is the current timestamp. The value will be generated by the front end. When the request returns the result, the setSerialNO of the user will be updated to the latest timestamp, indicating that the next time the user requests this interface, so the operation will not be repeated. For new and modified interfaces, an interceptor will be added to the back end to determine whether the request is invalid (duplicate request).
Every time the background gets SerialNO, it will compare the timestamp saved by the previous user in Redis. If the query is empty, or the timestamp is not equal, it means that the service has returned, indicating a new round of request.
If it is the same, the server did not return the result, it resubmits, throws an exception, the front end ignores the request, the request ends.
2. The front end requests the back end interface, and the back end generates the timestamp, saves it in Redis, and sends it to the front end in the response. When the next request comes, the back end will delete the timestamp in Redis and update it if it exists.
3. The front-end requests the back-end interface, and the back-end generates automicInteger each time according to the token and stores it in Redis. If the generated automicInteger in the new request is larger than the saved automicInteger in the last request in Redis, the result is returned. If this value is less than the automicINTEGER stored in the previous request in Redis, the request is ignored.
