Formats et contrats d’échange
ETag et catalogue voyage : revalider et éviter un écrasement
Une copie de catalogue et une modification d’offre ont des besoins différents. Conservez la représentation associée à son ETag, puis testez la relecture et le conflit de version sans confondre revalidation technique et disponibilité commerciale.
Le repère documentaire et sa portée
HTTP distingue la revalidation par If-None-Match et la condition de modification If-Match, qui utilise une comparaison forte des ETag. Sémantique HTTP documentée ; présence des ETag et prise en charge de ces conditions à confirmer pour chaque endpoint.
Définir la représentation suivie
Notez endpoint, paramètres utiles, compte, langue et marché. Un catalogue filtré ne se confond pas avec un autre périmètre. Conservez ensemble corps de réponse et validateur reçu ; une valeur isolée ne permet pas de savoir quelle copie reprendre. Faites préciser au fournisseur quels changements affectent sa représentation et quelles opérations acceptent une condition.
Distinguer relecture et protection de modification
Votre procédure doit nommer l’objectif : vérifier une copie ou éviter d’écraser un changement intervenu depuis sa lecture. Présentez ces deux cas à l’intégrateur avec les réponses attendues. Le contrat du catalogue reste nécessaire pour comprendre ce que la version couvre : contenu descriptif, tarif ou autre objet. Ne déduisez pas une réservation possible d’une copie revalidée.
Préparer le cas où la copie manque
Scénario fictif : le traitement possède un validateur mais a perdu le corps de catalogue correspondant. Faites montrer sa procédure de récupération. Un résultat de revalidation qui ne fournit pas un nouveau corps ne permet pas de reconstruire les fiches absentes. L’équipe doit pouvoir retrouver une copie cohérente ou relire complètement le périmètre autorisé.
Traiter un conflit au lieu de forcer le passage
Deux personnes modifient la même description depuis des lectures différentes. En recette, faites apparaître le changement concurrent puis la tentative fondée sur l’ancienne version. La reprise doit relire et présenter le conflit, pas retirer automatiquement la condition pour obtenir un succès. Séparez les champs réellement voulus des valeurs héritées d’une vieille copie.
Conserver les preuves de revalidation
Le registre contient la représentation, le validateur, l’opération, la réponse observée et la reprise choisie. Si l’endpoint ne prend pas en charge le mécanisme, gardez cette limite et utilisez la procédure contractuelle disponible. La méthode ne suppose pas que tous les fournisseurs voyage implémentent les conditions HTTP.
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- IETF HTTP Working Group : RFC 9110, HTTP Semantics — Sémantique HTTP documentée ; présence des ETag et prise en charge de ces conditions à confirmer pour chaque endpoint. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Un ETag est-il la date de modification ?
Traitez-le comme le validateur de la représentation selon le contrat. N’en déduisez ni date ni contenu métier sans documentation.
Que faire après un conflit de version ?
Relisez l’état courant, rapprochez le changement demandé et faites arbitrer les différences avant une nouvelle tentative autorisée.
Une copie revalidée garantit-elle le prix au paiement ?
Le parcours commercial doit effectuer ses contrôles prévus. La preuve de catalogue ne remplace pas la vérification de l’offre utilisée.