Embarquer un site existant en js natif dans une appli mobile

=== Contexte : description du projet

le projet a pour objectif la dématérialisation des tickets de caisse.

il fournit une api vendeur qui réceptionne les tickets.

l’utilisateur peut visualiser les tickets à l’aide d’un QrCode.

l’utilisateur peut stocker ses tickets dans son portefeuille virtuel.

différentes méthodes de rattachement sont prévues afin de limiter le nombre d’opérations en caisse et de prendre en charge différents types de caisse avec notamment des divergences en terme de capacité à présenter un écran ou à scanner ce qu’on leur présente.

=== Existant

API : une caisse peut envoyer les données des tickets associés à un nombre quelconque d’identifiants autres (numéro de cb, carte de fidélité…)

API : en réponse, la caisse est notifiée d’un rattachement à un compte utilisateur existant

API : en réponse, la caisse reçoit un id permettant de générer le QrCode qui permettra à l’utilisateur de récupérer son ticket.

les ids sont désordonnés et en apparence aléatoires. il est difficile de deviner le numéro des tickets passés ou futurs.

l’utilisateur final peut créer son compte et s’authentifier

le protocole utilisé est inspiré de mysql native authentication.

l’utilisateur peut s’identifier auprès de la caisse avec un QrCode

l’utilisateur peut visualiser un ticket à l’aide du QrCode associé

l’utilisateur peut rattacher un ticket à son compte si il en possède le QrCode et si le ticket n’est pas déjà attaché à un autre compte.

l’utilisateur final peut générer des statistiques basées sur les tickets qui lui appartiennent

=== Realisations attendues

génération d’un Service Worker.

le SW réalise la synchro des tickets de l’utilisateur (code existant pub/sync.js utilisé par la page stats.js)

la synchro est différenciée par série d’ids en modulo ( par exemple, si on est modulo 2, on synchronise séparément les ids pairs et impairs )

appli mobile : on souhaite embarquer le site web existant (en js natif) dans une webview

backoffices admin et vendeurs

avancées en cours. intérgration dqs stat et une poignée de CRUD simples. à définir. ne pas inclure dans le chiffrage initial

complétion de l’API vendeurs avec fonctionnalités encore à l'étude (en fonction des demandes partenaires)

incitation à l’utilisation de connexions persistantes

3 ou 4 POST+PUT sur du clé-valeur simple

sécurité API : à priori soit mTLS soit token + ip. l’essentiel est réalisé mais les ips sont pour l’instant hard codées au lieu d'être récupérées en base pour chaque client.

documentation de l’API inline quand on appelle l’api en GET sans paramètres (avec un content-type adapté ?). code de retour 406 ?

pay per phone. optionnel. à n’inclure dans le chiffrage que si vous avez une connaissance dans le domaine.

synchronisation avec base de produits en ligne

créations de liens vendeurs et partenaires en fonction du code article

export d’une liste de ticket pointés individuellement et/ou filtrés

génération de liens associés comprenant un token garantissant que l'émetteur est propriétaire des tickets en question.