Request Mocker modifie le trafic réseau dans le navigateur sans toucher au backend : bloquez les requêtes, définissez ou supprimez les en-têtes de requête et de réponse, et renvoyez vos propres codes d'état, corps et délais afin que vous puissiez tester les états que la véritable API ne produira pas à la demande.
Certains États sont extrêmement difficiles à atteindre. Un tableau de bord vide a besoin d'une réponse vide, une bannière de nouvelle tentative a besoin d'un 500, un squelette de chargement a besoin d'un point de terminaison lent et un frontend a besoin d'un point de terminaison qui n'existe pas encore. Normalement, chacun signifie un changement de backend, une base de données prédéfinie ou une ligne commentée que vous espérez ne pas expédier.
Request Mocker produit ces états dans le navigateur. Faites correspondre une URL par sous-chaîne ou avec des caractères génériques, puis décidez de ce qui se passe : bloquez la demande pour que la page voit un échec, réécrivez les en-têtes de demande ou de réponse à la volée, ou renvoyez une réponse standardisée avec le code d'état, le type de contenu, le corps et le délai de votre choix. La page ne peut pas faire la différence, donc votre véritable gestion des erreurs, vos états vides et vos délais d'attente fonctionnent tous pour de vrai.
Le blocage et la réécriture d'en-tête utilisent les règles déclarativeNetRequest de Chrome, elles s'appliquent donc à tout ce que la page demande, y compris lors du rechargement. Les fausses réponses sont servies pour récupérer et XMLHttpRequest depuis l'intérieur de la page, et le panneau enregistre chacune d'entre elles au fur et à mesure qu'elle est servie avec un compteur d'accès par règle, afin que vous puissiez voir en un coup d'œil si votre règle correspond à ce que vous pensez.
Les règles sont volontairement faciles à supprimer. Ils sont enregistrés par site, s'appliquent uniquement à l'onglet actuel et chacun d'entre eux est supprimé au moment où vous fermez l'outil. Il n'y a donc aucun moyen de passer un après-midi à déboguer un problème qui s'avère être une simulation que vous avez oublié d'exécuter.
Empêchez une requête de partir, correspondant à l'URL et à la méthode, et observez le comportement de la page lorsqu'un script, une image, un tracker ou un appel d'API n'arrive tout simplement jamais.
Définissez ou supprimez les en-têtes de demande et de réponse : ajoutez un en-tête d'autorisation, forcez Cache-Control : no-store ou supprimez un en-tête pour voir ce qui se casse, sans aucun changement de serveur.
Présentez un corps que vous écrivez avec le code de statut et le type de contenu que vous choisissez. Parfait pour les listes vides, les charges utiles mal formées et les points de terminaison qui n'existent pas encore.
Renvoyez un 500, un 429 ou un 404 à la demande et ajoutez un délai en millisecondes pour retenir la réponse afin que les états de chargement, les spinners et la gestion des délais d'attente puissent être testés correctement.
Faites correspondre librement avec un fragment comme /api/users, ou précisément avec des caractères génériques comme *.example.com/v1/*, et limitez n'importe quelle règle à une seule méthode HTTP.
Les règles appartiennent au site sur lequel vous les avez créées et s'appliquent uniquement à l'onglet actuel. La fermeture de l'outil supprime toutes les règles actives, donc rien ne continue d'intercepter le trafic dans votre dos.
Renvoyez un tableau vide pour un point de terminaison de liste et voyez si votre interface utilisateur affiche un état vide approprié ou un panneau vide gênant.
Faites en sorte qu'un point de terminaison renvoie 500 ou 429 à la demande pour vérifier que la bannière de nouvelle tentative, le toast et la copie de secours apparaissent réellement.
Moquez-vous de la forme de réponse convenue et construisez l'ensemble du frontend pendant que le backend est encore en cours d'écriture.
Bloquez un script d'analyse, de chat ou de publicité pour confirmer si c'est ce qui ralentit la page ou brise une mise en page.
Ajoutez un délai de deux secondes à un point de terminaison et observez comment les squelettes, les compteurs et les délais d'attente résistent lorsqu'un seul appel est en retard.
Cliquez sur l'icône Request Mocker dans le dock DevSuite Pro. Le panneau s'ouvre avec un formulaire de règles en haut et vos règles enregistrées pour ce site en dessous.
Choisissez Demande de blocage, Modifier les en-têtes ou Réponse simulée et limitez éventuellement la règle à une méthode telle que POST.
Entrez une sous-chaîne telle que /api/users ou utilisez des caractères génériques tels que *.example.com/v1/*. Choisissez si la règle couvre uniquement les appels de récupération et XHR ou tous les types de requêtes.
Pour les en-têtes, écrivez-les un par ligne — Nom : valeur pour en définir un, Nom : seul pour le supprimer. Pour une simulation, définissez le statut, le délai, le type de contenu et le corps. Cliquez sur Ajouter une règle et elle s'applique immédiatement.
Rechargez ou utilisez la page et le journal affiche chaque fausse réponse au fur et à mesure de sa diffusion, avec un nombre d'accès à côté de chaque règle. Basculez, modifiez ou supprimez des règles au fur et à mesure ; la fermeture de l'outil les efface tous.
Installez DevSuite Pro gratuitement et débloquez plus de 71 outils de développement pour votre navigateur.
