Erreurs et codes
Objectif
Traiter correctement une erreur d'API, en distinguant ce qui se réessaie de ce qui demande une action humaine.
Structure d'une erreur
Une réponse d'erreur porte un statut HTTP, un code applicatif stable et un message destiné au journal, pas à l'utilisateur final. Le code applicatif est ce sur quoi un client doit brancher sa logique : les messages peuvent être reformulés, les codes non.
Trois familles à distinguer
Les erreurs transitoires (réseau, indisponibilité temporaire) se réessaient avec un intervalle croissant. Les erreurs d'authentification demandent un renouvellement de jeton, puis une reconnexion. Les erreurs métier (période fermée, écart d'effectif, affectation manquante) ne se réessaient jamais telles quelles : elles demandent une action.
Cas particulier du bordereau refusé
Un refus de soumission est une erreur métier. Aucune écriture partielle n'a eu lieu côté serveur, et le client doit conserver intégralement la saisie locale plutôt que de la vider.
Ce qu'il ne faut jamais journaliser
Jeton, mot de passe, ou donnée scolaire nominative. Un journal client doit rester exploitable sans exposer d'élève.
Cette page vous a-t-elle aidé ?
Toujours bloqué ? Écrivez au support : support@modernschools.online