Écrire les états avant de dessiner l’animation
Voici un parcours proposé pour votre application de randonnée, pas un relevé du comportement observé de l’API. La personne saisit offline maps, demande des discussions historiques et attend. L’application doit distinguer un formulaire non utilisé, une requête en cours, des données reçues, une réponse vide réussie et un échec. Un seul panneau blanc ne communique pas toutes ces situations.
Commencez par un écran neutre expliquant ce qui sera recherché. La saisie ne doit pas nécessairement déclencher de requête. Lors de l’envoi explicite, associez la question à la requête et affichez un libellé de chargement. Gardez le texte lisible et empêchez les pressions répétées d’envoyer plusieurs fois la même action. L’animation signale une attente, pas une progression prouvée dans l’archive.
Relier la réponse tardive à sa question
Imaginez que la personne remplace la saisie par régions téléchargées pendant que la requête offline maps attend toujours. C’est une interaction illustrative, pas un exemple récupéré. Votre application doit décider d’attendre, de lancer une autre requête ou de permettre la fermeture de la vue. Quel que soit le choix, l’ancienne réponse ne doit pas devenir silencieusement celle de la nouvelle expression.
Associez chaque requête à la saisie envoyée dans l’état de votre application. À son arrivée, vérifiez si la réponse appartient encore à la vue actuelle. Écarter une réponse tardive de l’écran ne revient pas à annuler le travail du serveur : une requête déjà partie peut réussir et être facturée. Testez cette distinction dans votre implémentation.
Traiter une réponse vide réussie comme un résultat
Si des données arrivent, montrez les champs disponibles et gardez l’indication de source historique. Si data est vide, utilisez un message distinct indiquant que cette requête n’a renvoyé aucun enregistrement. Proposez de modifier l’expression ou les filtres, tout en les conservant pour une décision éclairée. Ne remplacez pas une réponse vide par des publications populaires inventées.
Une récupération vide réussie coûte un crédit, comme une réponse contenant des données. Cela justifie de modifier les termes volontairement, pas de dissimuler les résultats vides comme des erreurs. Évitez d’affirmer qu’aucune discussion pertinente n’existe : l’archive est incomplète et la réponse correspond à une requête et une fenêtre données.
Confier le problème technique à l’opérateur
Une réponse 400 invite à vérifier les paramètres. Si l’application a envoyé une date invalide ou un paramètre non accepté, ne reprochez pas au lecteur une erreur de contrat du serveur. Un 401 indique une clé du service absente ou invalide ; recharger l’application ou demander au lecteur de se connecter ne répare pas nécessairement cette clé.
Un 402 indique que le compte du service manque de crédits. Adressez cette décision à l’opérateur sans montrer de facture au randonneur. Un 429 exige de respecter Retry-After et de réduire les répétitions. Le compte pouvant être partagé entre lecteurs, n’affirmez pas automatiquement qu’une personne a provoqué la limite.
Séparer l’échec connu de l’issue inconnue
Le gateway renvoie 502 lorsqu’une récupération échoue en amont. Le crédit réservé est libéré ou sa restitution est signalée comme en attente de régularisation. Gardez la question et toute page antérieure visible, puis proposez un nouvel essai limité. Des répétitions automatiques peuvent générer d’autres requêtes sans aider à comprendre ce qui s’est passé.
Si l’application ne reçoit aucune réponse, elle peut ignorer si le serveur a échoué ou terminé. Consignez cette incertitude pour la régularisation ; n’annoncez pas une restitution ou une réussite certaine. La route publique /v1/status ne vérifie qu’une déclaration statique et la réponse HTTP : elle ne résout pas cette question et ne certifie pas l’état de la recherche.
Examiner les transitions, pas seulement les captures
Parcourez le scénario avec la personne responsable de l’application : envoyer, modifier pendant l’attente, recevoir un résultat vide, recommencer après échec, charger une page et quitter. Pour chaque transition, nommez la saisie conservée, le contenu visible et la prochaine action. Une jolie maquette ne prouve pas que ces transitions fonctionnent.
Gardez les diagnostics de l’opérateur, les réponses brutes et les identifiants hors des messages publics. Donnez au lecteur assez de contexte pour poursuivre la préparation sans dépendre d’une recherche indisponible. Retrouvez sur /fr/#field-notes les décisions de budget et d’affichage de la suite qui structurent ce parcours.
