30. Revalidation et mises à jour conditionnelles

Comprendre le mécanisme

Une requête conditionnelle utilise un validateur comme un ETag ou une date selon le mécanisme prévu. If-None-Match intervient notamment dans la revalidation d’une représentation ; une réponse 304 permet alors d’éviter de renvoyer un corps complet dans le cas applicable. If-Match exprime un prérequis utile pour certaines mutations, afin de ne pas modifier une version différente de celle que le client croit traiter.

Raisonner et vérifier

Un ETag n’est pas une preuve d’autorisation. Pour prévenir une mise à jour perdue, le serveur doit relier le prérequis à l’écriture de façon cohérente : une comparaison suivie d’un UPDATE non protégé peut encore courir avec un autre traitement. Définissez aussi l’usage de validateurs forts ou faibles selon le contrat de l’opération. Testez le cas où deux clients partent de la même version.

Validateur

Un ETag peut servir de validateur de représentation. La version de contenu n’est pas une identité. Un ETag identifie une version de représentation selon sa construction. Il ne donne pas de droit d’accès ; le serveur doit le relier à la bonne ressource et au bon contexte utilisateur.

Réutilisation 304

Une réponse 304 réutilise une représentation selon le contexte. La réponse de non-modification n’envoie pas ce contenu complet. Une réponse 304 pertinente permet au client de réutiliser une représentation qu’il possède selon le contrat de revalidation. Elle ne transporte pas normalement un nouveau corps complet de cette représentation.

Lecture conditionnelle

If-None-Match peut conditionner une lecture. Le champ exprime une condition sur un validateur. If-None-Match permet de demander si une version possédée reste actuelle. Vérifiez le cas correspondant et le cas modifié, avec les headers nécessaires à la mise à jour du cache.

Écriture conditionnelle

If-Match peut protéger une écriture concurrente. Une modification peut survenir entre les deux étapes. If-Match peut exprimer que la mutation n’est admise que sur la version connue. Cela aide à éviter qu’un client écrase une modification concurrente qu’il n’a pas encore observée.

Lien atomique

La comparaison et l’écriture doivent être cohérentes. Le contrôle doit porter sur l’état au moment de la transition. Comparer la version puis écrire plus tard sans protection laisse une course. Utilisez une mise à jour conditionnelle ou une transaction adaptée et contrôlez le nombre de lignes effectivement modifiées.

Précondition échouée

Un échec de précondition peut empêcher une mise à jour perdue. Le refus doit précéder l’effet non admis. Si la version a changé, refusez selon le contrat plutôt qu’appliquer silencieusement l’écriture. Le client peut alors relire, fusionner ou demander confirmation avec un état à jour.

Droit de lecture

Le droit de lecture doit rester vérifié. Le validateur ne donne pas la permission. Un validateur connu ne suffit pas à obtenir une donnée. Vérifiez l’autorisation avant de répondre, y compris lorsqu’un 304 pourrait révéler l’existence ou l’état d’une ressource confidentielle.

Bonne représentation

Un validateur doit correspondre à la représentation considérée. Il doit refléter le contrat de comparaison choisi. Une version calculée pour une vue publique n’est pas automatiquement celle d’une vue personnalisée. Définissez quelle représentation l’ETag désigne et gardez cette portée dans la sélection et les tests.

Faible ou fort

Les validateurs faibles et forts ne sont pas interchangeables partout. Les règles de comparaison dépendent de l’usage. Les validateurs faibles et forts ne sont pas acceptés de façon interchangeable dans toutes les préconditions. Appliquez les règles du protocole pour l’opération choisie au lieu de retirer simplement le préfixe faible.

Deux écrivains

Le test de concurrence doit inclure deux écrivains. La course doit être observée ou simulée. Faites lire la version sept à deux clients puis lancez leurs écritures. Une seule doit gagner si la politique exige une version exacte ; vérifiez le contenu final et le refus de l’autre.

Atelier guidé : lire, expliquer et vérifier le code

UPDATE lab_documents
SET content = 'new', version = version + 1
WHERE id = 42 AND version = 7;

Le prédicat id=42 AND version=7 lie la précondition à la modification SQL. Si une première écriture a déjà produit version huit, cette requête ne modifie aucune ligne. L’application doit vérifier ce résultat et le traduire en échec de précondition, sans annoncer un succès fictif.

Le SET ne s’applique pas à une ligne hors du prédicat. Le prédicat conditionne l’écriture. La permission est un contrôle distinct de cette concurrence. Le prédicat refuse la ligne dont la version vaut déjà 8.

Travail pratique : Avec deux clients de laboratoire, modifiez une même ressource depuis la version initiale puis tentez d’appliquer la seconde modification.

Critères de correction : Utilisez une version persistante et une écriture conditionnelle. Vérifiez que le second client reçoit le refus prévu et recharge l’état au lieu d’écraser silencieusement la première modification. Testez aussi le contrôle d’accès.