Sessions mobiles et synchronisation hors ligne
Le canal utilisateur et ses différences avec une app connectée.
Connexion utilisateur#
Un client mobile utilise une session de personne avec ses droits. Il ne doit pas embarquer un secret d'app connectée partagé par tous les utilisateurs.
Le client ouvre le parcours de connexion dans le navigateur système. Après connexion, le serveur renvoie un jeton de relais à usage unique vers une adresse de retour autorisée. Le client échange ce relais auprès de POST /api/auth/handoff/mobile, puis stocke le jeton de session dans le stockage sécurisé de l'appareil.
Le relais expire rapidement et ne se réutilise pas. Une WebView n'est pas un substitut au navigateur système pour les clés d'accès. La liste des schémas de retour est fermée.
Appels REST au nom de la personne#
La session est portée par Authorization: Bearer. Les droits et la visibilité sont ceux de l'utilisateur. Une désactivation ou révocation doit être traitée comme une perte d'accès, pas comme une panne à contourner avec un autre jeton.
Le renouvellement passe par le parcours de session. Les routes métier ne prolongent pas nécessairement la session à chaque lecture.
Synchronisation#
Le canal /api/v1/sync prend en charge les lectures incrémentales et les mutations hors ligne selon son contrat. Il est distinct des listes REST ordinaires et de leur idempotence par app.
Conservez les identifiants de mutations, la version de base et les curseurs de synchronisation. Après une coupure, reprenez l'opération logique au lieu d'en créer une nouvelle. Rendez visibles les opérations en attente, rejetées ou en conflit.
Gestion des conflits#
Une fusion de champs et des contrôles métier peuvent produire un résultat différent de la saisie locale initiale. Présentez ce résultat à la personne et rechargez l'état serveur. Ne considérez pas un HTTP réussi comme la preuve que tous les champs locaux ont gagné.
Versions et données locales#
Les métadonnées publiques décrivent les capacités et la version minimale acceptée. Si le serveur exige une mise à jour, bloquez les parcours incompatibles avec une explication exploitable.
À la déconnexion ou au changement d'organisation, appliquez le cloisonnement et les règles de purge du stockage local. Une base locale n'est pas une source indépendante des droits serveur.
Lire le résultat de synchronisation#
GET /api/v1/sync/pull renvoie les changements ainsi que les retraits du périmètre et les suppressions physiques. Appliquez aussi removals et tombstones au stockage local : ne conserver que changes laisserait des fiches devenues non autorisées sur l'appareil.
POST /api/v1/sync/push traite un lot ordonné et renvoie une issue par mutation. Une mutation peut être applied, merged, conflict ou rejected. En cas de fusion, examinez les champs écrasés signalés ; en cas de rejet, affichez la raison et gardez la possibilité de résoudre la saisie localement.
Les types de mutations acceptés sont fermés et versionnés. Consultez la référence sync pour la liste et les contraintes de lot de votre contrat. Un client ne peut pas transformer n'importe quel PATCH REST en mutation hors ligne.