Partager via

Tester des API web avec HttpRepl

  • Article

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]

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

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 :

%HOME%/.httpreplprefs

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.name n’a pas de valeur, colors.json.string est utilisée.
  • Si colors.json.string n’a pas de valeur, colors.json.literal est utilisée.
  • Si colors.json.literal n’a pas de valeur, colors.json est utilisée.
  • Si colors.json n’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 de la mise en retrait de la réponse est actuellement prise en charge pour JSON uniquement. 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 :

pref set editor.command.default "/usr/bin/code"

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.json
  • swagger/v1/swagger.json
  • /swagger.json
  • /swagger/v1/swagger.json
  • openapi.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-formatting

    Indicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.

  • -h|--header

    Définit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :

    • {header}={value}
    • {header}:{value}

  • --response:body

    Spé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:headers

    Spé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|--streaming

    Indicateur dont la présence provoque l’activation du streaming de la réponse HTTP.

Exemple

Pour émettre une requête HTTP GET :

  1. Exécutez la commande get sur un point de terminaison qui la prend en charge :

    https://localhost:5001/people> get

    La 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>

  2. Récupérez un enregistrement spécifique en passant un paramètre à la commande get :

    https://localhost:5001/people> get 2

    La 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-formatting

    Indicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.

  • -h|--header

    Définit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :

    • {header}={value}
    • {header}:{value}

  • --response:body

    Spé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:headers

    Spé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|--streaming

    Indicateur dont la présence provoque l’activation du streaming de la réponse HTTP.

  • -c|--content

    Fournit un corps de requête HTTP inline. Par exemple, -c "{\"id\":2,\"name\":\"Cherry\"}"

  • -f|--file

    Fournit un chemin vers un fichier contenant le corps de la requête HTTP. Par exemple, -f "C:\request.json"

  • --no-body

    Indique qu’aucun corps de requête HTTP n’est nécessaire.

Exemple

Pour émettre une requête HTTP POST :

  1. Exécutez la commande post sur un point de terminaison qui la prend en charge :

    https://localhost:5001/people> post -h Content-Type=application/json

    Dans la commande précédente, l’en-tête Content-Type de 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.

  2. Modifiez le modèle JSON pour répondre aux exigences de validation du modèle :

    {
  "id": 0,
  "name": "Scott Addie"
}

  3. 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-formatting

    Indicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.

  • -h|--header

    Définit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :

    • {header}={value}
    • {header}:{value}

  • --response:body

    Spé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:headers

    Spé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|--streaming

    Indicateur dont la présence provoque l’activation du streaming de la réponse HTTP.

  • -c|--content

    Fournit un corps de requête HTTP inline. Par exemple, -c "{\"id\":2,\"name\":\"Cherry\"}"

  • -f|--file

    Fournit un chemin vers un fichier contenant le corps de la requête HTTP. Par exemple, -f "C:\request.json"

  • --no-body

    Indique qu’aucun corps de requête HTTP n’est nécessaire.

Exemple

Pour émettre une requête HTTP PUT :

  1. Facultatif : exécutez la commande get pour 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"
  }
]

  2. Exécutez la commande put sur un point de terminaison qui la prend en charge :

    https://localhost:5001/fruits> put 2 -h Content-Type=application/json

    Dans la commande précédente, l’en-tête Content-Type de 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.

  3. Modifiez le modèle JSON pour répondre aux exigences de validation du modèle :

    {
  "id": 2,
  "name": "Cherry"
}

  4. 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: Kestrel

  5. Facultatif : lancez une commande get pour voir les modifications. Par exemple, si vous avez tapé « Cherry » dans l’éditeur de texte, une commande get retourne 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-formatting

    Indicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.

  • -h|--header

    Définit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :

    • {header}={value}
    • {header}:{value}

  • --response:body

    Spé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:headers

    Spé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|--streaming

    Indicateur dont la présence provoque l’activation du streaming de la réponse HTTP.

Exemple

Pour émettre une requête HTTP DELETE :

  1. Facultatif : exécutez la commande get pour 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"
  }
]

  2. Exécutez la commande delete sur un point de terminaison qui la prend en charge :

    https://localhost:5001/fruits> delete 2

    La 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: Kestrel

  3. Facultatif : lancez une commande get pour voir les modifications. Dans cet exemple, une commande get retourne 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-formatting

    Indicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.

  • -h|--header

    Définit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :

    • {header}={value}
    • {header}:{value}

  • --response:body

    Spé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:headers

    Spé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|--streaming

    Indicateur dont la présence provoque l’activation du streaming de la réponse HTTP.

  • -c|--content

    Fournit un corps de requête HTTP inline. Par exemple, -c "{\"id\":2,\"name\":\"Cherry\"}"

  • -f|--file

    Fournit un chemin vers un fichier contenant le corps de la requête HTTP. Par exemple, -f "C:\request.json"

  • --no-body

    Indique 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-formatting

    Indicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.

  • -h|--header

    Définit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :

    • {header}={value}
    • {header}:{value}

  • --response:body

    Spé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:headers

    Spé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|--streaming

    Indicateur 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-formatting

    Indicateur dont la présence provoque la suppression de la mise en forme de la réponse HTTP.

  • -h|--header

    Définit un en-tête de requête HTTP. Les deux formats de fichier suivants sont pris en charge :

    • {header}={value}
    • {header}:{value}

  • --response:body

    Spé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:headers

    Spé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|--streaming

    Indicateur 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/json

    Avec 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/json

    Si 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é :

  1. Définissez la préférence httpClient.useDefaultCredentials sur true :

    pref set httpClient.useDefaultCredentials true

  2. Quittez 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é :

  1. Définissez la préférence httpClient.proxy.useDefaultCredentials sur true :

    pref set httpClient.proxy.useDefaultCredentials true

  2. Quittez 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.

  1. Connectez-vous à Azure :

    az login

  2. Obtenez votre ID d’abonnement avec la commande suivante :

    az account show --query id

  3. Copiez votre ID d’abonnement et exécutez la commande suivante :

    az account set --subscription "<SUBSCRIPTION ID>"

  4. Obtenez votre jeton de porteur avec la commande suivante :

    az account get-access-token --query accessToken

  5. Connectez-vous à l’API REST Azure via HttpRepl :

    httprepl https://management.azure.com

  6. Définissez l’en-tête de requête HTTP Authorization :

    https://management.azure.com/> set header Authorization "bearer <ACCESS TOKEN>"

  7. Accédez à l’abonnement :

    https://management.azure.com/> cd subscriptions/<SUBSCRIPTION ID>

  8. 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-01

    La 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 :

  1. 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 1

  2. Exécutez la commande run, en passant le chemin du fichier texte. Par exemple :

    https://localhost:5001/> run C:\http-repl-scripts\people-script.txt

    Vous 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