Simuler une réponse d'API sur un appareil réel

Ouvrez le flux du dashboard et trouvez une requête réelle vers l'endpoint. Si sa ligne montre un corps déchiffré, vous êtes prêt. Si l'hôte apparaît encore chiffré, ajoutez-le à la liste SSL proxy de l'appareil — depuis les actions d'hôte de la ligne, ou dans les réglages de l'appareil — et déclenchez l'appel à nouveau. Sur un hôte qui passe chiffré, le moteur ne peut filtrer que sur le nom d'hôte ; le chemin est invisible, donc un mock précis au chemin ne se déclenche jamais.

Ouvrez la page Blocks depuis la navigation des réglages pour une règle globale, ou allez sur l'appareil puis Blocks pour une règle qui ne s'applique qu'à ce téléphone. Ajoutez une règle et renseignez la méthode — ou laissez-la vide pour tout accepter — et le motif. Les motifs sont les mêmes jokers hôte-plus-chemin que ceux des points d'arrêt : l'hôte, une barre oblique, le chemin, avec un astérisque là où un segment varie.

Réglez l'action sur Mock. Là où Block sert à faire échouer un appel et Drop à faire croire que le réseau a disparu, Mock sert à le satisfaire : définissez le statut — 200 par défaut —, les en-têtes que l'app va regarder, et le corps. Donnez-lui le Content-Type que votre app analyse ; un client JSON qui reçoit une réponse texte échouera avant d'en lire un octet. Enregistrée en JSON, la règle ressemble à ceci.

Enregistrez la règle et utilisez l'app. La prochaine requête correspondante reçoit sa réponse sans jamais quitter le chemin de capture, et elle apparaît toujours dans votre flux — marquée comme simulée, pour que vous voyiez exactement ce qui a été falsifié et confirmiez que la règle a fait ce que vous attendiez. L'app ne voit qu'une réponse serveur ordinaire : les réponses synthétiques ne portent aucun en-tête interne ou identifiant, donc rien dans la réponse ne révèle l'interception.

Désactivez la règle avec son interrupteur quand vous avez terminé. Une règle désactivée ne coûte rien et garde sa forme pour la prochaine fois.

Certains mocks doivent n'arriver qu'une fois. Le cas classique est un 401 synthétique qui fait croire à l'app que son jeton a expiré pour qu'elle lance son flux de rafraîchissement — répondez ainsi à chaque requête et l'app rafraîchit, réessaie, reçoit un autre 401 et tourne à l'infini. Le champ Max runs plafonne le nombre de déclenchements d'une règle ; au plafond elle se désactive d'elle-même et l'éditeur affiche un badge auto-désactivée, distinct d'une règle que vous auriez coupée vous-même.

Le compteur est tenu par appareil et survit aux reconnexions et aux relances de l'app, donc un plafond de un ne se déclenche qu'une seule fois sur ce téléphone, pas une fois par session. Une règle globale plafonnée n'est supprimée que sur l'appareil qui l'a épuisée et continue de se déclencher sur tous les autres téléphones de la flotte. Vous pouvez aussi demander à BusyBro, en langage naturel, un mock 401 à usage unique sur un hôte : il écrit la même règle.

Un corps Mock est une chaîne figée. Quand la réponse doit dépendre de la requête — un identifiant renvoyé, un horodatage, un champ patché dans la vraie réponse — passez l'action de la règle sur Script, ou créez un script autonome sous Settings puis Scripts. Vous disposez d'un éditeur de code avec autocomplétion pour les objets de requête, de réponse et d'aide, et d'un panneau Test qui exécute votre script sur une entrée capturée réelle et affiche un diff avant-après sans toucher au trafic en direct. L'essai à blanc utilise le sandbox identique à celui du proxy en production, donc réussir le test signifie que ça marche en réel.

Un script qui lève une exception ou dépasse le délai échoue en mode ouvert : les octets d'origine sont transmis et l'entrée est marquée dans l'inspecteur, si bien qu'un script cassé ne peut jamais bloquer une connexion ni se trahir auprès de l'app. Les scripts sont de niveau administrateur parce qu'ils exécutent du code arbitraire dans le chemin de capture.