Utilisez Etag pour implémenter un mécanisme de verrouillage optimiste dans le contrôle de concurrence. L'exemple suivant ne se limite pas aux soumissions répétées :

Dans un scénario simultané, lorsque plusieurs clients exploitent la même ressource en même temps, une situation se produira : la ressource exploitée par le client est modifiée dans des circonstances inconnues.

Un exemple simple :

L'utilisateur A a publié un message avec le contenu post-a. L'utilisateur B a vu post-a puis a écrit un commentaire ci-dessous. Pendant que B écrivait le commentaire, l'utilisateur A a modifié le contenu du message en post-aa. Un problème qui va se poser est que le commentaire écrit par l'utilisateur B pour post-a semble bizarre^_^

La solution est très simple. Lorsque B voit A, donnez-lui une balise d'identification de ressource de publication-1. Lorsque B soumet un commentaire, il le soumet avec cette balise d'identification-1. Le serveur vérifie les conditions a priori avant d'accepter la demande. S'il n'y a aucun changement dans le contenu de la publication à ce moment-là, il s'agit toujours de la balise 1, ce qui signifie le succès.

Si le contenu de la publication change, le nouvel ID est la balise-2, qui ne correspond pas à la balise-1 soumise par B, indiquant que les ressources ont changé au cours de la période, et 412 Precondition Failed est renvoyé. Actualisez ensuite la page ou l'invite, informez B de ce changement et continuez à commenter.

La situation de l'API est similaire, il vous suffit d'ajouter un identifiant aux ressources renvoyées.

Générez une valeur de hachage à partir des paramètres transmis et stockez-la dans le champ hash_code de la base de données. Ce champ est utilisé comme index unique. Et chaque fois qu'elle est insérée dans la base de données, une valeur de hachage est générée de la même manière pour déterminer si la valeur de hachage existe.