Tester des API web avec HttpRepl
La boucle REPL (Read-Eval-Print Loop) HTTP est :
- Un outil en ligne de commande léger et multiplateforme qui est pris en charge partout où .NET Core est pris en charge.
- Utilisée pour effectuer des requêtes HTTP pour tester des API web ASP.NET Core (et des API web ASP.NET Core non-ASP.NET) et voir leurs résultats.
- Capable de tester les API web hébergées dans n’importe quel environnement, notamment localhost et Azure App Service.
Les verbes HTTP suivants sont pris en charge :
Pour continuer, consultez ou téléchargez l’exemple d’API web ASP.NET Core (comment télécharger).
Prérequis
Installation
Pour installer HttpRepl, exécutez la commande suivante :
dotnet tool install -g Microsoft.dotnet-httprepl
Un outil global .NET Core est installé à partir du package NuGet Microsoft.dotnet-httprepl.
Remarque
Par défaut, l’architecture des fichiers binaires .NET à installer représente l’architecture du système d’exploitation en cours d’exécution. Pour spécifier une architecture de système d’exploitation différente, consultez dotnet tool install, --arch option. Pour plus d'informations, consultez le problème GitHub dotnet/AspNetCore.Docs n° 29262.
Sur macOS, mettez à jour le chemin d’accès :
export PATH="$HOME/.dotnet/tools:$PATH"
Utilisation
Une fois l’installation de l’outil réussie, exécutez la commande suivante pour démarrer HttpRepl :
httprepl
Pour voir les commandes HttpRepl disponibles, exécutez une des commandes suivantes :
httprepl -h
httprepl --help
Vous obtenez la sortie suivante :
Usage:
httprepl [<BASE_ADDRESS>] [options]
Arguments:
<BASE_ADDRESS> - The initial base address for the REPL.
Options:
-h|--help - Show help information.
Once the REPL starts, these commands are valid:
Setup Commands:
Use these commands to configure the tool for your API server
connect Configures the directory structure and base address of the api server
set header Sets or clears a header for all requests. e.g. `set header content-type application/json`
HTTP Commands:
Use these commands to execute requests against your application.
GET get - Issues a GET request
POST post - Issues a POST request
PUT put - Issues a PUT request
DELETE delete - Issues a DELETE request
PATCH patch - Issues a PATCH request
HEAD head - Issues a HEAD request
OPTIONS options - Issues a OPTIONS request
Navigation Commands:
The REPL allows you to navigate your URL space and focus on specific APIs that you are working on.
ls Show all endpoints for the current path
cd Append the given directory to the currently selected path, or move up a path when using `cd ..`
Shell Commands:
Use these commands to interact with the REPL shell.
clear Removes all text from the shell
echo [on/off] Turns request echoing on or off, show the request that was made when using request commands
exit Exit the shell
REPL Customization Commands:
Use these commands to customize the REPL behavior.
pref [get/set] Allows viewing or changing preferences, e.g. 'pref set editor.command.default 'C:\\Program Files\\Microsoft VS Code\\Code.exe'`
run Runs the script at the given path. A script is a set of commands that can be typed with one command per line
ui Displays the Swagger UI page, if available, in the default browser
Use `help <COMMAND>` for more detail on an individual command. e.g. `help get`.
For detailed tool info, see https://aka.ms/http-repl-doc.
HttpRepl offre la saisie semi-automatique des commandes. Un appui sur la touche Tab itère au sein de la liste des commandes qui complètent les caractères ou le point de terminaison d’API que vous avez tapés. Les sections suivantes décrivent les commandes CLI disponibles.
Se connecter à l’API web
Connectez-vous à une API web en exécutant la commande suivante :
httprepl <ROOT URI>
<ROOT URI> est l’URI de base pour l’API web. Par exemple :
httprepl https://localhost:5001
Vous pouvez aussi exécuter la commande suivante à tout moment pendant l’exécution de HttpRepl :
connect <ROOT URI>
Par exemple :
(Disconnected)> connect https://localhost:5001
Pointez manuellement vers la description OpenAPI pour l’API web
La commande connect ci-dessus tente de trouver automatiquement la description OpenAPI. Si pour une raison quelconque, elle n’y parvient pas, vous pouvez spécifier l’URI de la description OpenAPI pour l’API web en utilisant l’option --openapi :
connect <ROOT URI> --openapi <OPENAPI DESCRIPTION ADDRESS>
Par exemple :
(Disconnected)> connect https://localhost:5001 --openapi /swagger/v1/swagger.json
Activer la sortie détaillée pour des informations sur la recherche, l’analyse et la validation de la description OpenAPI
La spécification de l’option --verbose avec la commande connect va produire plus de détails quand l’outil recherche la description OpenAPI, l’analyse et la valide.
connect <ROOT URI> --verbose
Par exemple :
(Disconnected)> connect https://localhost:5001 --verbose
Checking https://localhost:5001/swagger.json... 404 NotFound
Checking https://localhost:5001/swagger/v1/swagger.json... 404 NotFound
Checking https://localhost:5001/openapi.json... Found
Parsing... Successful (with warnings)
The field 'info' in 'document' object is REQUIRED [#/info]
The field 'paths' in 'document' object is REQUIRED [#/paths]
Accéder à l’API web
Voir les points de terminaison disponibles
Pour lister les différents points de terminaison (contrôleurs) sur le chemin actuel de l’adresse de l’API web, exécutez la commande ls ou dir :
https://localhost:5001/> ls
Le format de sortie suivant s’affiche :
. []
Fruits [get|post]
People [get|post]
https://localhost:5001/>
La sortie précédente indique que deux contrôleurs sont disponibles : Fruits et People. Les deux contrôleurs prennent en charge les opérations HTTP GET et POST sans paramètres.
La navigation dans un contrôleur spécifique révèle plus de détails. Par exemple, la sortie de la commande suivante indique que le contrôleur Fruits prend également en charge les opérations HTTP GET, PUT et DELETE. Chacune de ces opérations attend un paramètre id dans la route :
https://localhost:5001/fruits> ls
. [get|post]
.. []
{id} [get|put|delete]
https://localhost:5001/fruits>
Vous pouvez également exécuter la commande ui pour ouvrir la page de l’interface utilisateur Swagger de l’API web dans un navigateur. Par exemple :
https://localhost:5001/> ui
Accéder à un point de terminaison
Pour accéder à un autre point de terminaison sur l’API web, exécutez la commande cd :
https://localhost:5001/> cd people
Le chemin qui suit la commande cd ne respecte pas la casse. Le format de sortie suivant s’affiche :
/people [get|post]
https://localhost:5001/people>
Personnaliser HttpRepl
Les couleurs par défaut de HttpRepl peuvent être personnalisées. Vous pouvez aussi définir un éditeur de texte par défaut. Les préférences de HttpRepl sont conservées dans la session active et sont appliquées dans les sessions ultérieures. Une fois modifiées, les préférences sont stockées dans le fichier suivant :
Le fichier .httpreplprefs est chargé au démarrage et ses modifications ne sont pas surveillées pendant l’exécution. Les modifications manuelles apportées au fichier prennent effet seulement après un redémarrage de l’outil.
Voir les paramètres
Pour voir les paramètres disponibles, exécutez la commande pref get. Par exemple :
https://localhost:5001/> pref get
La commande précédente affiche les paires clé-valeur disponibles :
colors.json=Green
colors.json.arrayBrace=BoldCyan
colors.json.comma=BoldYellow
colors.json.name=BoldMagenta
colors.json.nameSeparator=BoldWhite
colors.json.objectBrace=Cyan
colors.protocol=BoldGreen
colors.status=BoldYellow
Définir les préférences de couleur
La colorisation des réponses est actuellement prise en charge seulement pour JSON. Pour personnaliser les couleurs par défaut de HttpRepl, recherchez la clé correspondant à la couleur à changer. Pour des instructions sur la façon de trouver les clés, consultez la section Voir les paramètres. Par exemple, remplacez la valeur de la clé colors.json de Green par White :
https://localhost:5001/people> pref set colors.json White
Seules les couleurs autorisées peuvent être utilisées. Les requêtes HTTP suivantes affichent la sortie avec les nouvelles couleurs.
Quand des clés d’une couleur spécifique ne sont pas définies, des clés plus génériques sont prises en compte. Pour illustrer ce comportement de repli, considérez l’exemple suivant :
- Si
colors.json.namen’a pas de valeur,colors.json.stringest utilisée. - Si
colors.json.stringn’a pas de valeur,colors.json.literalest utilisée. - Si
colors.json.literaln’a pas de valeur,colors.jsonest utilisée. - Si
colors.jsonn’a pas de valeur, la couleur de texte par défaut de l’interpréteur de commandes (AllowedColors.None) est utilisée.
Définir la taille de la mise en retrait
La personnalisation de la taille d’indentation de la réponse est actuellement prise en charge seulement pour JSON. La taille par défaut est de deux espaces. Par exemple :
[
{
"id": 1,
"name": "Apple"
},
{
"id": 2,
"name": "Orange"
},
{
"id": 3,
"name": "Strawberry"
}
]
Pour changer la taille par défaut, définissez la clé formatting.json.indentSize. Par exemple, pour toujours utiliser quatre espaces :
pref set formatting.json.indentSize 4
Les réponses suivantes adoptent la valeur correspondant à quatre espaces :
[
{
"id": 1,
"name": "Apple"
},
{
"id": 2,
"name": "Orange"
},
{
"id": 3,
"name": "Strawberry"
}
]
Définir l’éditeur de texte par défaut
Par défaut, HttpRepl n’a pas d’éditeur de texte configuré pour l’utilisation. Pour tester les méthodes d’API web nécessitant un corps de requête HTTP, vous devez définir un éditeur de texte par défaut. L’outil HttpRepl lance l’éditeur de texte configuré dans le seul but de permettre la composition du corps de la requête. Exécutez la commande suivante pour définir votre éditeur de texte préféré comme éditeur par défaut :
pref set editor.command.default "<EXECUTABLE>"
Dans la commande précédente, <EXECUTABLE> est le chemin complet du fichier exécutable de l’éditeur de texte. Par exemple, exécutez la commande suivante pour définir Visual Studio Code comme éditeur de texte par défaut :
Pour lancer l’éditeur de texte par défaut avec des arguments CLI spécifiques, définissez la clé editor.command.default.arguments. Par exemple, supposons que Visual Studio Code est l’éditeur de texte par défaut et que vous voulez que HttpRepl ouvre toujours Visual Studio Code dans une nouvelle session avec les extensions désactivées. Exécutez la commande suivante :
pref set editor.command.default.arguments "--disable-extensions --new-window"
Conseil
Si votre éditeur par défaut est Visual Studio Code, vous voulez en général passer l’argument -w ou --wait pour forcer Visual Studio Code à attendre que vous fermiez le fichier avant de retourner.
Définir les chemins de recherche de description OpenAPI
Par défaut, HttpRepl a un ensemble de chemins relatifs qu’il utilise pour rechercher la description OpenAPI lors de l’exécution de la commande connect sans l’option --openapi. Ces chemins relatifs sont combinés avec les chemins racine et de base spécifiés dans la commande connect. Les chemins relatifs par défaut sont les suivants :
swagger.jsonswagger/v1/swagger.json/swagger.json/swagger/v1/swagger.jsonopenapi.json/openapi.json
Pour utiliser un autre ensemble de chemins de recherche dans votre environnement, définissez la préférence swagger.searchPaths. La valeur doit être une liste de chemins relatifs délimités par des barres verticales. Par exemple :
pref set swagger.searchPaths "swagger/v2/swagger.json|swagger/v3/swagger.json"
Au lieu de remplacer la liste par défaut, la liste peut également être modifiée en ajoutant ou en supprimant des chemins.
Pour ajouter un ou plusieurs chemins de recherche à la liste par défaut, définissez la préférence swagger.addToSearchPaths. La valeur doit être une liste de chemins relatifs délimités par des barres verticales. Par exemple :
pref set swagger.addToSearchPaths "openapi/v2/openapi.json|openapi/v3/openapi.json"
Pour supprimer un ou plusieurs chemins de recherche de la liste par défaut, définissez la préférence swagger.addToSearchPaths. La valeur doit être une liste de chemins relatifs délimités par des barres verticales. Par exemple :
pref set swagger.removeFromSearchPaths "swagger.json|/swagger.json"
Tester des requêtes HTTP GET
Synopsis
get <PARAMETER> [-F|--no-formatting] [-h|--header] [--response:body] [--response:headers] [-s|--streaming]
Arguments
PARAMETER
Paramètre de route, le cas échéant, attendu par la méthode d’action du contrôleur associé.
Options
Les options suivantes sont disponibles pour la commande get :
-F|--no-formattingIndicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.
-h|--headerDéfinit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :
{header}={value}{header}:{value}
--response:bodySpécifie un fichier dans lequel le corps de la réponse HTTP doit être écrit. Par exemple,
--response:body "C:\response.json"Le fichier est créé s’il n’existe pas.--response:headersSpécifie un fichier dans lequel les en-têtes de la réponse HTTP doivent être écrits. Par exemple,
--response:headers "C:\response.txt"Le fichier est créé s’il n’existe pas.-s|--streamingIndicateur dont la présence provoque l’activation du streaming de la réponse HTTP.
Exemple
Pour émettre une requête HTTP GET :
Exécutez la commande
getsur un point de terminaison qui la prend en charge :https://localhost:5001/people> getLa commande précédente affiche le format de sortie suivant :
HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Fri, 21 Jun 2019 03:38:45 GMT Server: Kestrel Transfer-Encoding: chunked [ { "id": 1, "name": "Scott Hunter" }, { "id": 2, "name": "Scott Hanselman" }, { "id": 3, "name": "Scott Guthrie" } ] https://localhost:5001/people>Récupérez un enregistrement spécifique en passant un paramètre à la commande
get:https://localhost:5001/people> get 2La commande précédente affiche le format de sortie suivant :
HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Fri, 21 Jun 2019 06:17:57 GMT Server: Kestrel Transfer-Encoding: chunked [ { "id": 2, "name": "Scott Hanselman" } ] https://localhost:5001/people>
Tester des requêtes HTTP POST
Synopsis
post <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]
Arguments
PARAMETER
Paramètre de route, le cas échéant, attendu par la méthode d’action du contrôleur associé.
Options
-F|--no-formattingIndicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.
-h|--headerDéfinit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :
{header}={value}{header}:{value}
--response:bodySpécifie un fichier dans lequel le corps de la réponse HTTP doit être écrit. Par exemple,
--response:body "C:\response.json"Le fichier est créé s’il n’existe pas.--response:headersSpécifie un fichier dans lequel les en-têtes de la réponse HTTP doivent être écrits. Par exemple,
--response:headers "C:\response.txt"Le fichier est créé s’il n’existe pas.-s|--streamingIndicateur dont la présence provoque l’activation du streaming de la réponse HTTP.
-c|--contentFournit un corps de requête HTTP inline. Par exemple,
-c "{\"id\":2,\"name\":\"Cherry\"}"-f|--fileFournit un chemin vers un fichier contenant le corps de la requête HTTP. Par exemple,
-f "C:\request.json"--no-bodyIndique qu’aucun corps de requête HTTP n’est nécessaire.
Exemple
Pour émettre une requête HTTP POST :
Exécutez la commande
postsur un point de terminaison qui la prend en charge :https://localhost:5001/people> post -h Content-Type=application/jsonDans la commande précédente, l’en-tête
Content-Typede la requête HTTP est défini pour indiquer un type de média de corps de requête JSON. L’éditeur de texte par défaut ouvre un fichier .tmp avec un modèle JSON représentant le corps de la requête HTTP. Par exemple :{ "id": 0, "name": "" }Conseil
Pour définir l’éditeur de texte par défaut, consultez la section Définir l’éditeur de texte par défaut.
Modifiez le modèle JSON pour répondre aux exigences de validation du modèle :
{ "id": 0, "name": "Scott Addie" }Enregistrez le fichier .tmp et fermez l’éditeur de texte. La sortie suivante s’affiche dans l’interpréteur de commandes :
HTTP/1.1 201 Created Content-Type: application/json; charset=utf-8 Date: Thu, 27 Jun 2019 21:24:18 GMT Location: https://localhost:5001/people/4 Server: Kestrel Transfer-Encoding: chunked { "id": 4, "name": "Scott Addie" } https://localhost:5001/people>
Tester des requêtes HTTP PUT
Synopsis
put <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]
Arguments
PARAMETER
Paramètre de route, le cas échéant, attendu par la méthode d’action du contrôleur associé.
Options
-F|--no-formattingIndicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.
-h|--headerDéfinit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :
{header}={value}{header}:{value}
--response:bodySpécifie un fichier dans lequel le corps de la réponse HTTP doit être écrit. Par exemple,
--response:body "C:\response.json"Le fichier est créé s’il n’existe pas.--response:headersSpécifie un fichier dans lequel les en-têtes de la réponse HTTP doivent être écrits. Par exemple,
--response:headers "C:\response.txt"Le fichier est créé s’il n’existe pas.-s|--streamingIndicateur dont la présence provoque l’activation du streaming de la réponse HTTP.
-c|--contentFournit un corps de requête HTTP inline. Par exemple,
-c "{\"id\":2,\"name\":\"Cherry\"}"-f|--fileFournit un chemin vers un fichier contenant le corps de la requête HTTP. Par exemple,
-f "C:\request.json"--no-bodyIndique qu’aucun corps de requête HTTP n’est nécessaire.
Exemple
Pour émettre une requête HTTP PUT :
Facultatif : exécutez la commande
getpour voir les données avant de les modifier :https://localhost:5001/fruits> get HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Sat, 22 Jun 2019 00:07:32 GMT Server: Kestrel Transfer-Encoding: chunked [ { "id": 1, "data": "Apple" }, { "id": 2, "data": "Orange" }, { "id": 3, "data": "Strawberry" } ]Exécutez la commande
putsur un point de terminaison qui la prend en charge :https://localhost:5001/fruits> put 2 -h Content-Type=application/jsonDans la commande précédente, l’en-tête
Content-Typede la requête HTTP est défini pour indiquer un type de média de corps de requête JSON. L’éditeur de texte par défaut ouvre un fichier .tmp avec un modèle JSON représentant le corps de la requête HTTP. Par exemple :{ "id": 0, "name": "" }Conseil
Pour définir l’éditeur de texte par défaut, consultez la section Définir l’éditeur de texte par défaut.
Modifiez le modèle JSON pour répondre aux exigences de validation du modèle :
{ "id": 2, "name": "Cherry" }Enregistrez le fichier .tmp et fermez l’éditeur de texte. La sortie suivante s’affiche dans l’interpréteur de commandes :
[main 2019-06-28T17:27:01.805Z] update#setState idle HTTP/1.1 204 No Content Date: Fri, 28 Jun 2019 17:28:21 GMT Server: KestrelFacultatif : lancez une commande
getpour voir les modifications. Par exemple, si vous avez tapé « Cherry » dans l’éditeur de texte, une commandegetretourne la sortie suivante :https://localhost:5001/fruits> get HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Sat, 22 Jun 2019 00:08:20 GMT Server: Kestrel Transfer-Encoding: chunked [ { "id": 1, "data": "Apple" }, { "id": 2, "data": "Cherry" }, { "id": 3, "data": "Strawberry" } ] https://localhost:5001/fruits>
Tester des requêtes HTTP DELETE
Synopsis
delete <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]
Arguments
PARAMETER
Paramètre de route, le cas échéant, attendu par la méthode d’action du contrôleur associé.
Options
-F|--no-formattingIndicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.
-h|--headerDéfinit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :
{header}={value}{header}:{value}
--response:bodySpécifie un fichier dans lequel le corps de la réponse HTTP doit être écrit. Par exemple,
--response:body "C:\response.json"Le fichier est créé s’il n’existe pas.--response:headersSpécifie un fichier dans lequel les en-têtes de la réponse HTTP doivent être écrits. Par exemple,
--response:headers "C:\response.txt"Le fichier est créé s’il n’existe pas.-s|--streamingIndicateur dont la présence provoque l’activation du streaming de la réponse HTTP.
Exemple
Pour émettre une requête HTTP DELETE :
Facultatif : exécutez la commande
getpour voir les données avant de les modifier :https://localhost:5001/fruits> get HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Sat, 22 Jun 2019 00:07:32 GMT Server: Kestrel Transfer-Encoding: chunked [ { "id": 1, "data": "Apple" }, { "id": 2, "data": "Orange" }, { "id": 3, "data": "Strawberry" } ]Exécutez la commande
deletesur un point de terminaison qui la prend en charge :https://localhost:5001/fruits> delete 2La commande précédente affiche le format de sortie suivant :
HTTP/1.1 204 No Content Date: Fri, 28 Jun 2019 17:36:42 GMT Server: KestrelFacultatif : lancez une commande
getpour voir les modifications. Dans cet exemple, une commandegetretourne la sortie suivante :https://localhost:5001/fruits> get HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Sat, 22 Jun 2019 00:16:30 GMT Server: Kestrel Transfer-Encoding: chunked [ { "id": 1, "data": "Apple" }, { "id": 3, "data": "Strawberry" } ] https://localhost:5001/fruits>
Tester des requêtes HTTP PATCH
Synopsis
patch <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]
Arguments
PARAMETER
Paramètre de route, le cas échéant, attendu par la méthode d’action du contrôleur associé.
Options
-F|--no-formattingIndicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.
-h|--headerDéfinit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :
{header}={value}{header}:{value}
--response:bodySpécifie un fichier dans lequel le corps de la réponse HTTP doit être écrit. Par exemple,
--response:body "C:\response.json"Le fichier est créé s’il n’existe pas.--response:headersSpécifie un fichier dans lequel les en-têtes de la réponse HTTP doivent être écrits. Par exemple,
--response:headers "C:\response.txt"Le fichier est créé s’il n’existe pas.-s|--streamingIndicateur dont la présence provoque l’activation du streaming de la réponse HTTP.
-c|--contentFournit un corps de requête HTTP inline. Par exemple,
-c "{\"id\":2,\"name\":\"Cherry\"}"-f|--fileFournit un chemin vers un fichier contenant le corps de la requête HTTP. Par exemple,
-f "C:\request.json"--no-bodyIndique qu’aucun corps de requête HTTP n’est nécessaire.
Tester des requêtes HTTP HEAD
Synopsis
head <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]
Arguments
PARAMETER
Paramètre de route, le cas échéant, attendu par la méthode d’action du contrôleur associé.
Options
-F|--no-formattingIndicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.
-h|--headerDéfinit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :
{header}={value}{header}:{value}
--response:bodySpécifie un fichier dans lequel le corps de la réponse HTTP doit être écrit. Par exemple,
--response:body "C:\response.json"Le fichier est créé s’il n’existe pas.--response:headersSpécifie un fichier dans lequel les en-têtes de la réponse HTTP doivent être écrits. Par exemple,
--response:headers "C:\response.txt"Le fichier est créé s’il n’existe pas.-s|--streamingIndicateur dont la présence provoque l’activation du streaming de la réponse HTTP.
Tester des requêtes HTTP OPTIONS
Synopsis
options <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]
Arguments
PARAMETER
Paramètre de route, le cas échéant, attendu par la méthode d’action du contrôleur associé.
Options
-F|--no-formattingIndicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.
-h|--headerDéfinit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :
{header}={value}{header}:{value}
--response:bodySpécifie un fichier dans lequel le corps de la réponse HTTP doit être écrit. Par exemple,
--response:body "C:\response.json"Le fichier est créé s’il n’existe pas.--response:headersSpécifie un fichier dans lequel les en-têtes de la réponse HTTP doivent être écrits. Par exemple,
--response:headers "C:\response.txt"Le fichier est créé s’il n’existe pas.-s|--streamingIndicateur dont la présence provoque l’activation du streaming de la réponse HTTP.
Définir des en-têtes de requête HTTP
Pour définir un en-tête de requête HTTP, utilisez une des approches suivantes :
Définir inline avec la requête HTTP. Par exemple :
https://localhost:5001/people> post -h Content-Type=application/jsonAvec l’approche précédente, chaque en-tête de requête HTTP distinct nécessite sa propre option
-h.Définir avant l’envoi de la requête HTTP. Par exemple :
https://localhost:5001/people> set header Content-Type application/jsonSi l’en-tête est défini avant l’envoi d’une requête, l’en-tête reste défini pour la durée de la session de l’interpréteur de commandes. Pour effacer l’en-tête, spécifiez une valeur vide. Par exemple :
https://localhost:5001/people> set header Content-Type
Tester les points de terminaison sécurisés
HttpRepl prend en charge le test des points de terminaison sécurisés des façons suivantes :
- Via les informations d’identification par défaut de l’utilisateur connecté.
- Via l’utilisation d’en-têtes de requête HTTP.
Informations d’identification par défaut
Considérez une API web que vous testez, qui est hébergée dans IIS et sécurisée avec l’authentification Windows. Vous voulez que les informations d’identification de l’utilisateur exécutant l’outil transitent vers les points de terminaison HTTP testés. Pour passer les informations d’identification par défaut de l’utilisateur connecté :
Définissez la préférence
httpClient.useDefaultCredentialssurtrue:pref set httpClient.useDefaultCredentials trueQuittez et redémarrez l’outil avant d’envoyer une autre requête à l’API web.
Informations d’identification du proxy par défaut
Considérez un scénario où l’API web que vous testez se trouve derrière un proxy sécurisé avec l’authentification Windows. Vous voulez que les informations d’identification de l’utilisateur exécutant l’outil transitent vers le proxy. Pour passer les informations d’identification par défaut de l’utilisateur connecté :
Définissez la préférence
httpClient.proxy.useDefaultCredentialssurtrue:pref set httpClient.proxy.useDefaultCredentials trueQuittez et redémarrez l’outil avant d’envoyer une autre requête à l’API web.
En-têtes de requête HTTP
Voici des exemples de schémas d’authentification et d’autorisation pris en charge :
- basic authentication
- Jetons de porteur JWT
- authentification digest
Par exemple, vous pouvez envoyer un jeton de porteur à un point de terminaison avec la commande suivante :
set header Authorization "bearer <TOKEN VALUE>"
Pour accéder à un point de terminaison hébergé par Azure ou pour utiliser l’API REST Azure, vous avez besoin d’un jeton du porteur. Utilisez les étapes suivantes pour obtenir un jeton de porteur pour votre abonnement Azure via Azure CLI. HttpRepl définit le jeton de porteur dans un en-tête de requête HTTP. Une liste d’applications web Azure App Service est récupérée.
Connectez-vous à Azure :
az loginObtenez votre ID d’abonnement avec la commande suivante :
az account show --query idCopiez votre ID d’abonnement et exécutez la commande suivante :
az account set --subscription "<SUBSCRIPTION ID>"Obtenez votre jeton de porteur avec la commande suivante :
az account get-access-token --query accessTokenConnectez-vous à l’API REST Azure via HttpRepl :
httprepl https://management.azure.comDéfinissez l’en-tête de requête HTTP
Authorization:https://management.azure.com/> set header Authorization "bearer <ACCESS TOKEN>"Accédez à l’abonnement :
https://management.azure.com/> cd subscriptions/<SUBSCRIPTION ID>Obtenez la liste des applications web Azure App Service de votre abonnement :
https://management.azure.com/subscriptions/{SUBSCRIPTION ID}> get providers/Microsoft.Web/sites?api-version=2016-08-01La réponse suivante est affichée :
HTTP/1.1 200 OK Cache-Control: no-cache Content-Length: 35948 Content-Type: application/json; charset=utf-8 Date: Thu, 19 Sep 2019 23:04:03 GMT Expires: -1 Pragma: no-cache Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff x-ms-correlation-request-id: <em>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</em> x-ms-original-request-ids: <em>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx;xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</em> x-ms-ratelimit-remaining-subscription-reads: 11999 x-ms-request-id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx x-ms-routing-request-id: WESTUS:xxxxxxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx { "value": [ <AZURE RESOURCES LIST> ] }
Activer/désactiver l’affichage des requêtes HTTP
Par défaut, l’affichage de la requête HTTP envoyée est supprimé. Il est possible de changer le paramètre correspondant pour la durée de la session de l’interpréteur de commandes.
Activer l’affichage des requêtes
Affichez la requête HTTP envoyée en exécutant la commande echo on. Par exemple :
https://localhost:5001/people> echo on
Request echoing is on
Les requêtes HTTP suivantes dans la session active affichent les en-têtes de requête. Par exemple :
https://localhost:5001/people> post
[main 2019-06-28T18:50:11.930Z] update#setState idle
Request to https://localhost:5001...
POST /people HTTP/1.1
Content-Length: 41
Content-Type: application/json
User-Agent: HTTP-REPL
{
"id": 0,
"name": "Scott Addie"
}
Response from https://localhost:5001...
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Date: Fri, 28 Jun 2019 18:50:21 GMT
Location: https://localhost:5001/people/4
Server: Kestrel
Transfer-Encoding: chunked
{
"id": 4,
"name": "Scott Addie"
}
https://localhost:5001/people>
Désactiver l’affichage des requêtes
Supprimez l’affichage de la requête HTTP envoyée en exécutant la commande echo off. Par exemple :
https://localhost:5001/people> echo off
Request echoing is off
Exécuter un script
Si vous exécutez fréquemment le même jeu de commandes HttpRepl, envisagez de les stocker dans un fichier texte. Les commandes placées dans le fichier sont de la même forme que celles exécutées manuellement sur la ligne de commande. Les commandes peuvent être exécutées de façon groupée avec la commande run. Par exemple :
Créez un fichier texte contenant un ensemble de commandes délimitées par des sauts de ligne. Pour illustrer ceci, considérez un fichier people-script.txt contenant les commandes suivantes :
set base https://localhost:5001 ls cd People ls get 1Exécutez la commande
run, en passant le chemin du fichier texte. Par exemple :https://localhost:5001/> run C:\http-repl-scripts\people-script.txtVous obtenez la sortie suivante :
https://localhost:5001/> set base https://localhost:5001 Using OpenAPI description at https://localhost:5001/swagger/v1/swagger.json https://localhost:5001/> ls . [] Fruits [get|post] People [get|post] https://localhost:5001/> cd People /People [get|post] https://localhost:5001/People> ls . [get|post] .. [] {id} [get|put|delete] https://localhost:5001/People> get 1 HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Fri, 12 Jul 2019 19:20:10 GMT Server: Kestrel Transfer-Encoding: chunked { "id": 1, "name": "Scott Hunter" } https://localhost:5001/People>
Effacer la sortie
Pour supprimer toutes les sorties écrites dans le shell de commandes par l’outil HttpRepl, exécutez la commande clear ou cls. À titre d’illustration, imaginez que l’interpréteur de commandes contient la sortie suivante :
httprepl https://localhost:5001
(Disconnected)> set base "https://localhost:5001"
Using OpenAPI description at https://localhost:5001/swagger/v1/swagger.json
https://localhost:5001/> ls
. []
Fruits [get|post]
People [get|post]
https://localhost:5001/>
Exécutez la commande suivante pour effacer la sortie :
https://localhost:5001/> clear
Après l’exécution de la commande précédente, l’interpréteur de commandes contient seulement la sortie suivante :
https://localhost:5001/>
Ressources supplémentaires
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour