Routes et données fictives

Une route est une méthode et un chemin, et ce que le mock répond à cet endroit. Créez des routes à la main quand il n’y a pas encore de spec, quand il vous faut quelques endpoints pour développer ou tester, ou pour répondre autrement que la spec sur un chemin. Les corps s’écrivent tels qu’ils sont envoyés, en JSON, en XML ou en texte, et peuvent contenir des données fictives régénérées à chaque requête.

Les routes créées à la main répondent après les routes en JavaScript du mock et avant les opérations de sa spec, s’il en sert une. Voir quelle réponse reçoit une requête.

Créer une routeCopy Anchor Link

Sur la page Mocks, créez un mock avec Nouveau mock (il démarre avec une route GET /users de cinq utilisateurs fictifs), ou ouvrez un mock existant. La carte Routes liste ses routes :

• La case à cocher désactive une route sans la supprimer ; une route désactivée ne répond à rien.
• Cliquez sur une route pour la modifier sous la liste.
• Ajouter une route en ajoute une nouvelle après la route sélectionnée.
• Faites un clic droit sur une route pour Dupliquer, Créer une requête, Copier l’adresse (pendant que le mock tourne), Monter, Descendre et Supprimer la route.

Chaque modification est enregistrée immédiatement, et un mock en cours d’exécution répond aussitôt avec. Édition › Annuler annule n’importe quelle modification, y compris la suppression d’une route. Quand deux routes activées ont la même méthode et le même chemin, la carte vous prévient : seule la première répond.

Méthode, chemin et résuméCopy Anchor Link

• Route : la méthode (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, ou ANY pour toutes les méthodes) et le chemin. Une requête HEAD va à une route GET, sans le corps.
• Les paramètres de chemin s’écrivent {id} ou :id, un par partie du chemin : /users/{id}, /files/{name}.json. :id est enregistré sous la forme {id}. Une route avec une partie littérale l’emporte sur une route avec un paramètre : /users/me répond avant /users/{id}.
• Le Résumé dit à quoi sert la route. Les requêtes créées à partir de la route le prennent comme nom.

RéponsesCopy Anchor Link

Une route a une ou plusieurs réponses. Les pastilles sous RÉPONSES permettent de passer de l’une à l’autre ; + en ajoute une. Chaque réponse a :

La réponse marquée d’une coche est la réponse Par défaut de la route ; Définir par défaut sur une autre la change. Le bouton corbeille supprime une réponse.

Choisir une réponseCopy Anchor Link

Une requête vers une route reçoit, dans cet ordre :

1. La réponse qu’elle demande : un en-tête Prefer: example=Not found ou Prefer: code=404, ou les en-têtes x-mock-response-name et x-mock-response-code de Postman.
2. La première réponse dont toutes les règles sont vérifiées.
3. La réponse par défaut de la route : celle que vous avez définie par défaut avec Définir par défaut, quelles que soient ses règles. Sur une route où vous n’en avez pas choisi, une première réponse dont les règles n’étaient pas vérifiées cède la place à la première réponse sans règles : « 409 pour la commande expédiée » en tête de liste ne répond donc pas à toutes les autres commandes.

Une règle examine une partie de la requête :

La valeur est le texte que la partie doit avoir. * signifie n’importe quelle valeur, tant qu’il y en a une ; une valeur vide signifie que la partie doit être absente. Une réponse qui a plusieurs règles ne répond que si toutes sont vérifiées. Une règle sans nom est ignorée tant que vous ne lui en donnez pas un.

Par exemple, une route GET /users/{id} peut répondre 200 avec un utilisateur par défaut, et une réponse 404 avec la règle Paramètre de chemin id vaut 0 :

curl -i http://127.0.0.1:4010/users/42    # 200, the user
curl -i http://127.0.0.1:4010/users/0     # 404

Corps avec des données fictivesCopy Anchor Link

Tout ce qui est entre {{ }} dans un corps ou dans la valeur d’un en-tête est rempli à l’arrivée de la requête : chaque requête peut donc recevoir de nouvelles données. Le reste du corps est envoyé tel que vous l’avez écrit.

{
  "id": "{{request.params.id}}",
  "name": "{{$randomFullName}}",
  "email": "{{$randomEmail}}",
  "company": "{{$randomCompanyName}}",
  "joined": "{{$randomDatePast}}"
}

Valeurs fictivesCopy Anchor Link

{{$randomFirstName}}, {{$randomEmail}}, {{$randomCity}}, {{$randomPrice}}, {{$randomUUID}} et environ 120 autres : noms et métiers, internet, adresses, numéros de téléphone, entreprises, finance, produits, dates, mots, lorem ipsum, fichiers, images et bases de données. Les noms sont les variables dynamiques de Postman : les modèles écrits pour Postman fonctionnent donc ici. Certaines prennent des arguments : {{$randomInt(1, 100)}}, {{$randomPrice(5, 50)}}, {{$randomLoremWords(5)}}, {{$randomElement(active, paused, closed)}}. Valeurs dynamiques les liste toutes.

Insérer une valeur au-dessus du corps place une valeur fictive à l’endroit du curseur : Données fictives les regroupe par catégorie.

Les mêmes valeurs fonctionnent dans les requêtes, où elles sont générées à chaque envoi. Voir valeurs dynamiques.

Éléments de la requêteCopy Anchor Link

Insérer une valeur › Requête les propose, avec les paramètres de chemin de la route.

ListesCopy Anchor Link

{{#repeat 10}} … {{/repeat}} écrit ce qui se trouve entre les deux autant de fois ; {{#repeat 2 8}} un nombre de fois compris entre les deux, choisi à chaque requête. Dans un corps JSON, les éléments sont séparés par des virgules à votre place. À l’intérieur, {{@number}} est le numéro de l’élément à partir de 1 et {{@index}} à partir de 0. Les répétitions peuvent être imbriquées.

[
  {{#repeat 5}}
  {
    "id": {{@number}},
    "name": "{{$randomProductName}}",
    "price": {{$randomPrice}}
  }
  {{/repeat}}
]

Un {{#repeat}} ou un {{/repeat}} seul sur sa ligne ne laisse pas de ligne vide derrière lui.

ÉchappementCopy Anchor Link

Les valeurs sont échappées selon l’endroit où elles arrivent : un nom contenant un guillemet ne casse donc jamais votre JSON :

• Dans un corps JSON (un Content-Type contenant json), les valeurs à l’intérieur d’une chaîne sont échappées comme du JSON. Une valeur hors des guillemets, comme {{$randomInt}} ou {{@number}}, est insérée telle quelle.
• En XML et en HTML (un Content-Type contenant xml ou html), &, <, > et les guillemets sont échappés partout.
• Les triples accolades n’échappent jamais : {{{request.body}}} insère le corps JSON de la requête en JSON.

{ "received": {{{request.body}}}, "at": "{{$isoTimestamp}}" }

Les jetons qu’Echolot ne connaît pas restent tels que vous les avez écrits. Une valeur qu’il ne peut pas produire, comme {{$randomInt(9, 1)}}, reste aussi telle quelle, et le journal en donne la raison. Un corps s’arrête à 16 Mo et une répétition à 10 000 éléments.

Les corps ne lisent rien d’autre : ni variables, ni environnements, ni secrets, ni fichiers de l’espace de travail ; un mock qui répond sur le réseau ne peut donc en divulguer aucun.

Données fixes : GénérerCopy Anchor Link

Les valeurs entre {{ }} donnent de nouvelles données à chaque requête. Pour répondre avec les mêmes données à chaque fois, cliquez sur Générer… au-dessus du corps :

• Avec Créer une liste : le corps est un élément, le corps devient une liste JSON de ce nombre d’Éléments, chacun créé à partir du corps.
• Sans cette option, les valeurs du corps sont remplies une seule fois.

Générer remplace le corps par le résultat ; Édition › Annuler rétablit le modèle. Depuis Terminal, echolot fake fait de même.

Requêtes à partir de routesCopy Anchor Link

Créer des requêtes dans la carte Routes crée un dossier portant le nom du mock avec une requête pour chaque route activée ; Créer une requête dans le menu contextuel d’une route en crée une pour cette route. Echolot ouvre la première requête.

• Le dossier a une variable baseUrl réglée sur l’adresse du mock, et chaque URL commence par elle : {{baseUrl}}/users/{{id}}. Faites pointer baseUrl vers la vraie API plus tard et les mêmes requêtes y vont.
• Les paramètres de chemin deviennent des variables de requête, valant 1 sauf si une règle de chemin de la réponse par défaut nomme une valeur.
• La requête porte le nom du résumé de la route.
• Le corps de requête de la route l’accompagne.

Le corps de requête d’une routeCopy Anchor Link

Corps de la requête, au bas d’une route, contient un corps et son Content-Type pour les requêtes créées à partir de la route, par exemple le JSON qu’accepte un POST /users. Il ne change pas ce que le mock répond ; les règles sur les champs du corps lisent ce que les requêtes envoient réellement.

Avec des agentsCopy Anchor Link

Quand l’ensemble d’outils Mocks est activé, les agents et l’Assistant créent aussi des routes. Demandez ce qu’il vous faut :

• « Créez un mock avec des routes pour lister, lire et créer des commandes, avec des données fictives, et démarrez-le. »
• « Ajoutez un 404 à GET /users/{id} quand l’id vaut 0. »
• « Créez des requêtes pour les routes du mock. »

Ils utilisent create_mock (avec un nom et des routes, sans spec), save_mock_route, delete_mock_route, generate_fake_data, list_fake_values et create_requests_from_mock. save_mock_route peut aussi transformer une réponse de l’historique en route ; ce qu’il copie est masqué comme tout ce que les agents lisent. Un agent qui supprime une route vous demande d’abord. Voir Agents.

Dans l’espace de travailCopy Anchor Link

Les routes vivent dans le fichier du mock, mocks/<name>.toml, sous la forme [[routes]] avec leurs [[routes.responses]] : lisibles dans un diff et partagées par Git. Voir fichiers de l’espace de travail.