Une modification enregistrée sur un téléphone apparaît à l’écran avant que le serveur ne l’ait reçue. Le protocole de synchronisation suit cette opération depuis son écriture dans la base locale jusqu’à sa confirmation par le serveur. Il conserve l’état d’envoi pour transmettre à nouveau l’opération après une interruption.
Considérons une application de suivi d’équipements dans laquelle une observation et une photographie sont saisies sur mobile, puis consultées depuis une interface web. Chaque opération doit conserver son identifiant entre les connexions, les retries et les appareils pour que le serveur distingue une nouvelle saisie d’un envoi répété.
Enregistrer une opération avant de la transmettre
Le téléphone conserve l’observation dans une base locale. L’écran lit cette base et indique si l’opération est enregistrée sur l’appareil, en attente d’envoi ou confirmée par le serveur. La saisie reste ainsi disponible pendant une coupure réseau. Cette séparation entre base locale, synchronisation et interface correspond à l’architecture Android pour les applications utilisables hors connexion.
La même transaction locale enregistre l’observation et l’opération à transmettre. Les deux écritures réussissent ou échouent ensemble, ce qui conserve la tâche de synchronisation avec les données saisies. La photographie peut être transférée séparément, avec son identifiant et son état d’envoi. L’observation reste consultable pendant le transfert de la pièce jointe.
Reconnaître un nouvel essai de la même opération
Une requête peut atteindre le serveur sans que sa réponse parvienne au téléphone. Après une interruption, l’application ignore donc parfois si l’écriture a eu lieu. Rejouer la requête est nécessaire, mais créer une seconde observation serait incorrect.
Dans cet exemple, chaque opération possède un identifiant produit avant son premier envoi. Le serveur conserve cet identifiant avec le résultat de l’écriture et reconnaît les essais suivants. La durée de conservation de cette trace doit couvrir la période pendant laquelle le téléphone peut rejouer l’opération. Une référence supprimée trop tôt réintroduirait le risque de doublon.
Cette reconnaissance ne dispense pas de vérifier les droits et le contenu. Un identifiant déjà associé à une observation ne doit pas servir à transmettre silencieusement une autre modification. Le contrat de l’API précise le résultat retourné pour un nouvel essai identique et pour un contenu différent.
Traiter les modifications concurrentes
Supposons maintenant que le dossier ait changé dans l’interface web pendant que le téléphone travaillait sur une copie ancienne. Le serveur doit pouvoir détecter cette situation. Une version attendue accompagne la modification ; si elle ne correspond plus, l’écriture peut être refusée pour comparaison. Les préconditions HTTP, dont If-Match, fournissent un mécanisme standard pour ce type de contrôle.
Deux observations nouvelles peuvent être conservées séparément. Lorsque deux appareils modifient le même enregistrement, le protocole peut fusionner les champs indépendants. Si les valeurs se contredisent, il conserve le conflit pour une résolution explicite. Une règle fondée uniquement sur l’horodatage le plus récent peut écraser une modification et dépend de la synchronisation des horloges.
L’interface traduit ces règles en états compréhensibles. Une observation enregistrée localement, une photographie en cours de transfert et un conflit à examiner ne sont pas trois variantes du même message d’erreur.
Vérifier le parcours complet
Les tests simulent une coupure après l’écriture du serveur, un redémarrage avant confirmation, un double envoi et des modifications concurrentes. Ils vérifient qu’une opération produit une seule observation, que la saisie locale reste disponible et qu’un conflit non fusionnable est présenté à l’utilisateur.
Le protocole relie ainsi le téléphone, l’API et les autres applications autour d’une définition commune de l’écriture. C’est cette définition qui permet d’ajouter un appareil ou une interface sans multiplier les interprétations d’un même dossier.
