Testen von Web-APIs mit HttpRepl
HTTP REPL (read–eval–print-Loop):
- Ein schlankes, plattformübergreifendes Befehlszeilentool, das überall unterstützt wird, wo .NET Core unterstützt wird
- wird zum Senden von HTTP-Anforderungen verwendet, mit denen ASP.NET Core-Web-APIs (und andere APIs) getestet werden können, und zum Überprüfen von deren Ergebnissen
- kann zum Testen von Web-APIs verwendet werden, die in beliebigen Umgebungen gehostet werden (einschließlich Localhost und Azure App Service)
Folgende HTTP-Verben werden unterstützt:
Sehen Sie sich die beispielhafte ASP.NET Core-Web-API an, oder laden Sie sie herunter (Downloadanleitung), um dem Artikel zu folgen.
Voraussetzungen
Installation
Führen Sie den folgenden Befehl aus, um HttpRepl zu installieren:
dotnet tool install -g Microsoft.dotnet-httprepl
Ein globales .NET Core-Tool wird über das NuGet-Paket Microsoft.dotnet-httprepl installiert.
Hinweis
Standardmäßig stellt die Architektur der zu installierenden .NET-Binärdateien die derzeit ausgeführte Betriebssystemarchitektur dar. Informationen zum Angeben einer anderen Betriebssystemarchitektur finden Sie unter dotnet tool install, --arch option. Weitere Informationen finden Sie unter GitHub Issue dotnet/docs #29262.
Aktualisieren Sie unter macOS den Pfad:
export PATH="$HOME/.dotnet/tools:$PATH"
Verwendung
Nach der erfolgreichen Installation des Tools können Sie folgenden Befehl ausführen, um HttpRepl zu starten:
httprepl
Führen Sie einen der folgenden Befehle aus, um eine Liste der verfügbaren HttpRepl-Befehle anzuzeigen:
httprepl -h
httprepl --help
Die folgende Ausgabe wird angezeigt:
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.
In HttpRepl können Befehle vervollständigt werden. Wenn Sie die TAB-TASTE drücken, können Sie die Liste der Befehle durchlaufen, die die eingegebenen Zeichen oder API-Endpunkte vervollständigen. In den folgenden Abschnitten werden die verfügbaren CLI-Befehle erläutert.
Herstellen einer Verbindung mit der Web-API
Stellen Sie mithilfe des folgenden Befehls eine Verbindung mit einer Web-API her:
httprepl <ROOT URI>
<ROOT URI> ist der Basis-URI für die Web-API. Beispiel:
httprepl https://localhost:5001
Alternativ können Sie den folgenden Befehl jederzeit ausführen, während HttpRepl ausgeführt wird:
connect <ROOT URI>
Beispiel:
(Disconnected)> connect https://localhost:5001
Manuelles Verweisen auf die OpenAPI-Beschreibung für die Web-API
Der oben genannte connect-Befehl versucht, die OpenAPI-Beschreibung automatisch zu finden. Wenn dies aus irgendeinem Grund nicht möglich ist, können Sie den URI der OpenAPI-Beschreibung für die Web-API mithilfe der Option --openapi angeben:
connect <ROOT URI> --openapi <OPENAPI DESCRIPTION ADDRESS>
Beispiel:
(Disconnected)> connect https://localhost:5001 --openapi /swagger/v1/swagger.json
Ausführliche Ausgabe aktivieren, um Details zum Suchen, Analysieren und Validieren der OpenAPI-Beschreibung anzuzeigen
Wenn Sie die --verbose-Option mit dem Befehl connect angeben, werden weitere Details generiert, wenn das Tool nach der OpenAPI-Beschreibung sucht, diese analysiert und validiert.
connect <ROOT URI> --verbose
Beispiel:
(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]
Navigieren in der Web-API
Anzeigen verfügbarer Endpunkte
Führen Sie den Befehl ls oder dir aus, um die unterschiedlichen Endpunkte (Controller) im aktuellen Pfad der Web-API-Adresse aufzulisten:
https://localhost:5001/> ls
Folgendes Ausgabeformat wird angezeigt:
. []
Fruits [get|post]
People [get|post]
https://localhost:5001/>
Die vorherige Ausgabe gibt an, dass die zwei Controller Fruits und People verfügbar sind. Beide Controller unterstützen parameterlose HTTP GET- und HTTP POST-Vorgänge.
Wenn Sie zu einem bestimmten Controller navigieren, werden weitere Details angezeigt. Aus der Ausgabe des folgenden Befehls geht beispielsweise hervor, dass der Controller Fruits auch HTTP GET-, HTTP PUT- und HTTP DELETE-Vorgänge unterstützt. Jeder dieser Vorgänge erwartet einen id-Parameter in der Route:
https://localhost:5001/fruits> ls
. [get|post]
.. []
{id} [get|put|delete]
https://localhost:5001/fruits>
Führen Sie alternativ den Befehl ui aus, um die Swagger-Benutzeroberflächenseite der Web-API in einem Browser zu öffnen. Beispiel:
https://localhost:5001/> ui
Navigieren zu einem Endpunkt
Führen Sie den Befehl cd aus, um zu einem anderen Endpunkt in der Web-API zu navigieren:
https://localhost:5001/> cd people
Für den Pfad im Befehl cd wird die Groß-/Kleinschreibung nicht beachtet. Folgendes Ausgabeformat wird angezeigt:
/people [get|post]
https://localhost:5001/people>
Anpassen von HttpRepl
Die Standardfarben von HttpRepl können angepasst werden. Außerdem kann definiert werden, welcher Text-Editor standardmäßig verwendet wird. Die HttpRepl-Einstellungen werden in der aktuellen Sitzung beibehalten und in zukünftigen Sitzungen berücksichtigt. Nach der Änderung werden die Einstellungen in der folgenden Datei gespeichert:
Die HTTPREPLPREFS-Datei wird beim Start geladen und bei der Laufzeit nicht auf Änderungen überwacht. Manuelle Änderungen an der Datei werden erst nach dem Neustart des Tools wirksam.
Anzeigen der Einstellungen
Führen Sie den Befehl pref get aus, um die verfügbaren Einstellungen anzuzeigen. Beispiel:
https://localhost:5001/> pref get
Mit dem vorangehenden Befehl werden die verfügbaren Schlüssel-Wert-Paare angezeigt:
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
Festlegen von Farbeinstellungen
Die farbliche Kennzeichnung von Antworten wird derzeit nur für JSON unterstützt. Sie können die Standardfarben des HttpRepl-Tools anpassen, indem Sie den Schlüssel für die entsprechende Farbe suchen und ändern. Weitere Informationen zum Suchen von Schlüsseln finden Sie im Abschnitt Anzeigen der Einstellungen. Ändern Sie beispielsweise den Wert des Schlüssels colors.json folgendermaßen von Green in White:
https://localhost:5001/people> pref set colors.json White
Es können nur die zulässigen Farben verwendet werden. Nachfolgende HTTP-Anforderungen zeigen die Ausgabe mit der neuen Farbgebung an.
Wenn bestimmte Farbtasten nicht festgelegt sind, werden mehr generische Schlüssel berücksichtigt. Anhand des folgenden Beispiels wird das Fallbackverhalten veranschaulicht:
- Wenn
colors.json.namekeinen Wert aufweist, wirdcolors.json.stringverwendet. - Wenn
colors.json.stringkeinen Wert aufweist, wirdcolors.json.literalverwendet. - Wenn
colors.json.literalkeinen Wert aufweist, wirdcolors.jsonverwendet. - Wenn
colors.jsonkeinen Wert aufweist, wird die Standardtextfarbe (AllowedColors.None) der Befehlsshell verwendet.
Festlegen der Einzugsgröße
Die Anpassung der Einzugsgröße für Antworten wird derzeit nur für JSON unterstützt. Der Standardgröße beträgt zwei Leerzeichen. Beispiel:
[
{
"id": 1,
"name": "Apple"
},
{
"id": 2,
"name": "Orange"
},
{
"id": 3,
"name": "Strawberry"
}
]
Legen Sie den Schlüssel formatting.json.indentSize fest, um die Standardgröße zu ändern. Folgendermaßen werden beispielsweise immer vier Leerzeichen verwendet:
pref set formatting.json.indentSize 4
Nachfolgende Antworten berücksichtigen die Einstellung auf vier Leerzeichen:
[
{
"id": 1,
"name": "Apple"
},
{
"id": 2,
"name": "Orange"
},
{
"id": 3,
"name": "Strawberry"
}
]
Festlegen des Standard-Text-Editors
Standardmäßig ist für HttpRepl kein Text-Editor konfiguriert. Wenn Sie Web-API-Methoden testen möchten, für die ein HTTP-Anforderungstext erforderlich ist, müssen Sie einen Standard-Text-Editor festlegen. Das HttpRepl-Tool startet den konfigurierten Text-Editor nur zum Verfassen des Anforderungstexts. Führen Sie den folgenden Befehl aus, um Ihren bevorzugten Text-Editor festzulegen:
pref set editor.command.default "<EXECUTABLE>"
Im vorherigen Befehl ist <EXECUTABLE> der vollständige Pfad zur ausführbaren Datei des Text-Editors. Führen Sie beispielsweise folgenden Befehl aus, um Visual Studio Code als Standard-Text-Editor festzulegen:
Legen Sie den Schlüssel editor.command.default.arguments fest, um den Standard-Text-Editor mit bestimmten CLI-Argumenten zu starten. Nehmen Sie beispielsweise an, dass Visual Studio Code der Standard-Text-Editor ist und Sie möchten, dass Visual Studio Code durch HttpRepl immer in einer neuen Sitzung mit deaktivierten Erweiterungen öffnet. Führen Sie den folgenden Befehl aus:
pref set editor.command.default.arguments "--disable-extensions --new-window"
Tipp
Wenn Ihr Standard-Editor Visual Studio Code ist, sollten Sie normalerweise das -w- oder --wait-Argument übergeben, um Visual Studio Code zu zwingen, auf das Schließen der Datei zu warten, bevor die Rückgabe erfolgt.
Festlegen der Suchpfade der OpenAPI-Beschreibung
Standardmäßig weist die HttpReplL eine Reihe von relativen Pfaden auf, die zum Suchen nach der OpenAPI-Beschreibung verwendet werden, wenn der connect-Befehl ohne die Option --openapi ausgeführt wird. Diese relativen Pfade werden mit den Stamm- und Basispfaden kombiniert, die im connect-Befehl angegeben werden. Die standardmäßigen relativen Pfade lauten wie folgt:
swagger.jsonswagger/v1/swagger.json/swagger.json/swagger/v1/swagger.jsonopenapi.json/openapi.json
Um andere Suchpfade in Ihrer Umgebung zu verwenden, legen Sie die Einstellung swagger.searchPaths fest. Bei dem Wert muss es sich um eine durch Pipezeichen getrennte Liste relativer Pfade handeln. Beispiel:
pref set swagger.searchPaths "swagger/v2/swagger.json|swagger/v3/swagger.json"
Anstatt die Standardliste vollständig zu ersetzen, kann die Liste auch durch Hinzufügen oder Entfernen von Pfaden geändert werden.
Wenn Sie der Standardliste mindestens einen Suchpfad hinzufügen möchten, legen Sie die Einstellung swagger.addToSearchPaths fest. Bei dem Wert muss es sich um eine durch Pipezeichen getrennte Liste relativer Pfade handeln. Beispiel:
pref set swagger.addToSearchPaths "openapi/v2/openapi.json|openapi/v3/openapi.json"
Wenn Sie mindestens einen Suchpfad aus der Standardliste entfernen möchten, legen Sie die Einstellung swagger.addToSearchPaths fest. Bei dem Wert muss es sich um eine durch Pipezeichen getrennte Liste relativer Pfade handeln. Beispiel:
pref set swagger.removeFromSearchPaths "swagger.json|/swagger.json"
Testen von HTTP GET-Anforderungen
Übersicht
get <PARAMETER> [-F|--no-formatting] [-h|--header] [--response:body] [--response:headers] [-s|--streaming]
Argumente
PARAMETER
Der Routenparameter (sofern vorhanden), der von der zugeordneten Aktionsmethode des Controllers erwartet wird.
Tastatur
Für den Befehl get sind die folgenden Optionen verfügbar:
-F|--no-formattingEin Flag, das die Unterdrückung der HTTP-Antwortformatierung bewirkt.
-h|--headerLegt einen HTTP-Anforderungsheader fest. Die folgenden zwei Werteformate werden unterstützt:
{header}={value}{header}:{value}
--response:bodyGibt eine Datei an, in die der HTTP-Antworttext geschrieben werden soll. Beispiel:
--response:body "C:\response.json". Wenn die Datei nicht vorhanden ist, wird sie erstellt.--response:headersGibt eine Datei an, in die die HTTP-Antwortheader geschrieben werden sollen. Beispiel:
--response:headers "C:\response.txt". Wenn die Datei nicht vorhanden ist, wird sie erstellt.-s|--streamingEin Flag, das das Streaming der HTTP-Antwort aktiviert.
Beispiel
So führen Sie eine HTTP GET-Anforderung aus:
Führen Sie den Befehl
getfür einen Endpunkt aus, der ihn unterstützt:https://localhost:5001/people> getÜber den vorherigen Befehl wird das folgende Ausgabeformat angezeigt:
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>Rufen Sie einen bestimmten Datensatz ab, indem Sie einen Parameter an den Befehl
getübergeben:https://localhost:5001/people> get 2Über den vorherigen Befehl wird das folgende Ausgabeformat angezeigt:
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>
Testen von HTTP POST-Anforderungen
Übersicht
post <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]
Argumente
PARAMETER
Der Routenparameter (sofern vorhanden), der von der zugeordneten Aktionsmethode des Controllers erwartet wird.
Tastatur
-F|--no-formattingEin Flag, das die Unterdrückung der HTTP-Antwortformatierung bewirkt.
-h|--headerLegt einen HTTP-Anforderungsheader fest. Die folgenden zwei Werteformate werden unterstützt:
{header}={value}{header}:{value}
--response:bodyGibt eine Datei an, in die der HTTP-Antworttext geschrieben werden soll. Beispiel:
--response:body "C:\response.json". Wenn die Datei nicht vorhanden ist, wird sie erstellt.--response:headersGibt eine Datei an, in die die HTTP-Antwortheader geschrieben werden sollen. Beispiel:
--response:headers "C:\response.txt". Wenn die Datei nicht vorhanden ist, wird sie erstellt.-s|--streamingEin Flag, das das Streaming der HTTP-Antwort aktiviert.
-c|--contentStellt einen Inline-HTTP-Anforderungstext bereit. Beispiel:
-c "{\"id\":2,\"name\":\"Cherry\"}".-f|--fileStellt einen Pfad zu einer Datei bereit, die den HTTP-Anforderungstext enthält. Beispiel:
-f "C:\request.json".--no-bodyGibt an, dass kein HTTP-Anforderungstext benötigt wird.
Beispiel
So führen Sie eine HTTP POST-Anforderung aus:
Führen Sie den Befehl
postfür einen Endpunkt aus, der ihn unterstützt:https://localhost:5001/people> post -h Content-Type=application/jsonIm vorherigen Befehl wird der HTTP-Anforderungsheader
Content-Typeso festgelegt, dass er den Medientyp des Anforderungstexts (JSON) angibt. Der Standard-Text-Editor öffnet eine TMP-Datei mit einer JSON-Vorlage, die den HTTP-Anforderungstext darstellt. Beispiel:{ "id": 0, "name": "" }Tipp
Weitere Informationen zum Festlegen des Standard-Text-Editors Abschnitt Festlegen des Standard-Text-Editors.
Ändern Sie die JSON-Vorlage so, dass die Anforderungen für die Modellvalidierung erfüllt werden:
{ "id": 0, "name": "Scott Addie" }Speichern Sie die TMP-Datei, und schließen Sie den Text-Editor. In der Befehlsshell wird die folgende Ausgabe angezeigt:
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>
Testen von HTTP PUT-Anforderungen
Übersicht
put <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]
Argumente
PARAMETER
Der Routenparameter (sofern vorhanden), der von der zugeordneten Aktionsmethode des Controllers erwartet wird.
Tastatur
-F|--no-formattingEin Flag, das die Unterdrückung der HTTP-Antwortformatierung bewirkt.
-h|--headerLegt einen HTTP-Anforderungsheader fest. Die folgenden zwei Werteformate werden unterstützt:
{header}={value}{header}:{value}
--response:bodyGibt eine Datei an, in die der HTTP-Antworttext geschrieben werden soll. Beispiel:
--response:body "C:\response.json". Wenn die Datei nicht vorhanden ist, wird sie erstellt.--response:headersGibt eine Datei an, in die die HTTP-Antwortheader geschrieben werden sollen. Beispiel:
--response:headers "C:\response.txt". Wenn die Datei nicht vorhanden ist, wird sie erstellt.-s|--streamingEin Flag, das das Streaming der HTTP-Antwort aktiviert.
-c|--contentStellt einen Inline-HTTP-Anforderungstext bereit. Beispiel:
-c "{\"id\":2,\"name\":\"Cherry\"}".-f|--fileStellt einen Pfad zu einer Datei bereit, die den HTTP-Anforderungstext enthält. Beispiel:
-f "C:\request.json".--no-bodyGibt an, dass kein HTTP-Anforderungstext benötigt wird.
Beispiel
So führen Sie eine HTTP PUT-Anforderung aus:
Optional: Führen Sie den Befehl
getaus, um die Daten vor dem Ändern anzuzeigen: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" } ]Führen Sie den Befehl
putfür einen Endpunkt aus, der ihn unterstützt:https://localhost:5001/fruits> put 2 -h Content-Type=application/jsonIm vorherigen Befehl wird der HTTP-Anforderungsheader
Content-Typeso festgelegt, dass er den Medientyp des Anforderungstexts (JSON) angibt. Der Standard-Text-Editor öffnet eine TMP-Datei mit einer JSON-Vorlage, die den HTTP-Anforderungstext darstellt. Beispiel:{ "id": 0, "name": "" }Tipp
Weitere Informationen zum Festlegen des Standard-Text-Editors Abschnitt Festlegen des Standard-Text-Editors.
Ändern Sie die JSON-Vorlage so, dass die Anforderungen für die Modellvalidierung erfüllt werden:
{ "id": 2, "name": "Cherry" }Speichern Sie die TMP-Datei, und schließen Sie den Text-Editor. In der Befehlsshell wird die folgende Ausgabe angezeigt:
[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: KestrelOptional: Führen Sie den Befehl
getaus, um die Änderungen anzuzeigen. Wenn Sie beispielsweise „Cherry“ in den Text-Editor eingeben, gibtgetdie folgende Ausgabe zurück: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>
Testen von HTTP DELETE-Anforderungen
Übersicht
delete <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]
Argumente
PARAMETER
Der Routenparameter (sofern vorhanden), der von der zugeordneten Aktionsmethode des Controllers erwartet wird.
Tastatur
-F|--no-formattingEin Flag, das die Unterdrückung der HTTP-Antwortformatierung bewirkt.
-h|--headerLegt einen HTTP-Anforderungsheader fest. Die folgenden zwei Werteformate werden unterstützt:
{header}={value}{header}:{value}
--response:bodyGibt eine Datei an, in die der HTTP-Antworttext geschrieben werden soll. Beispiel:
--response:body "C:\response.json". Wenn die Datei nicht vorhanden ist, wird sie erstellt.--response:headersGibt eine Datei an, in die die HTTP-Antwortheader geschrieben werden sollen. Beispiel:
--response:headers "C:\response.txt". Wenn die Datei nicht vorhanden ist, wird sie erstellt.-s|--streamingEin Flag, das das Streaming der HTTP-Antwort aktiviert.
Beispiel
So führen Sie eine HTTP DELETE-Anforderung aus:
Optional: Führen Sie den Befehl
getaus, um die Daten vor dem Ändern anzuzeigen: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" } ]Führen Sie den Befehl
deletefür einen Endpunkt aus, der ihn unterstützt:https://localhost:5001/fruits> delete 2Über den vorherigen Befehl wird das folgende Ausgabeformat angezeigt:
HTTP/1.1 204 No Content Date: Fri, 28 Jun 2019 17:36:42 GMT Server: KestrelOptional: Führen Sie den Befehl
getaus, um die Änderungen anzuzeigen. In diesem Beispiel gibtgetdie folgende Ausgabe zurück: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>
Testen von HTTP PATCH-Anforderungen
Übersicht
patch <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]
Argumente
PARAMETER
Der Routenparameter (sofern vorhanden), der von der zugeordneten Aktionsmethode des Controllers erwartet wird.
Tastatur
-F|--no-formattingEin Flag, das die Unterdrückung der HTTP-Antwortformatierung bewirkt.
-h|--headerLegt einen HTTP-Anforderungsheader fest. Die folgenden zwei Werteformate werden unterstützt:
{header}={value}{header}:{value}
--response:bodyGibt eine Datei an, in die der HTTP-Antworttext geschrieben werden soll. Beispiel:
--response:body "C:\response.json". Wenn die Datei nicht vorhanden ist, wird sie erstellt.--response:headersGibt eine Datei an, in die die HTTP-Antwortheader geschrieben werden sollen. Beispiel:
--response:headers "C:\response.txt". Wenn die Datei nicht vorhanden ist, wird sie erstellt.-s|--streamingEin Flag, das das Streaming der HTTP-Antwort aktiviert.
-c|--contentStellt einen Inline-HTTP-Anforderungstext bereit. Beispiel:
-c "{\"id\":2,\"name\":\"Cherry\"}".-f|--fileStellt einen Pfad zu einer Datei bereit, die den HTTP-Anforderungstext enthält. Beispiel:
-f "C:\request.json".--no-bodyGibt an, dass kein HTTP-Anforderungstext benötigt wird.
Testen von HTTP HEAD-Anforderungen
Übersicht
head <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]
Argumente
PARAMETER
Der Routenparameter (sofern vorhanden), der von der zugeordneten Aktionsmethode des Controllers erwartet wird.
Tastatur
-F|--no-formattingEin Flag, das die Unterdrückung der HTTP-Antwortformatierung bewirkt.
-h|--headerLegt einen HTTP-Anforderungsheader fest. Die folgenden zwei Werteformate werden unterstützt:
{header}={value}{header}:{value}
--response:bodyGibt eine Datei an, in die der HTTP-Antworttext geschrieben werden soll. Beispiel:
--response:body "C:\response.json". Wenn die Datei nicht vorhanden ist, wird sie erstellt.--response:headersGibt eine Datei an, in die die HTTP-Antwortheader geschrieben werden sollen. Beispiel:
--response:headers "C:\response.txt". Wenn die Datei nicht vorhanden ist, wird sie erstellt.-s|--streamingEin Flag, das das Streaming der HTTP-Antwort aktiviert.
Testen von HTTP OPTIONS-Anforderungen
Übersicht
options <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]
Argumente
PARAMETER
Der Routenparameter (sofern vorhanden), der von der zugeordneten Aktionsmethode des Controllers erwartet wird.
Tastatur
-F|--no-formattingEin Flag, das die Unterdrückung der HTTP-Antwortformatierung bewirkt.
-h|--headerLegt einen HTTP-Anforderungsheader fest. Die folgenden zwei Werteformate werden unterstützt:
{header}={value}{header}:{value}
--response:bodyGibt eine Datei an, in die der HTTP-Antworttext geschrieben werden soll. Beispiel:
--response:body "C:\response.json". Wenn die Datei nicht vorhanden ist, wird sie erstellt.--response:headersGibt eine Datei an, in die die HTTP-Antwortheader geschrieben werden sollen. Beispiel:
--response:headers "C:\response.txt". Wenn die Datei nicht vorhanden ist, wird sie erstellt.-s|--streamingEin Flag, das das Streaming der HTTP-Antwort aktiviert.
Festlegen von HTTP-Anforderungsheadern
Verwenden Sie einen der folgenden Ansätze, um einen HTTP-Anforderungsheader festzulegen:
Legen Sie den Header inline mit der HTTP-Anforderung fest. Beispiel:
https://localhost:5001/people> post -h Content-Type=application/jsonBeim vorherigen Ansatz benötigt jeder eindeutige HTTP-Anforderungsheader eine eigene
-h-Option.Legen Sie den Header fest, bevor Sie die HTTP-Anforderung senden. Beispiel:
https://localhost:5001/people> set header Content-Type application/jsonWenn Sie den Header vor dem Senden einer Anforderung festlegen, bleibt er für die Dauer der Befehlsshellsitzung festgelegt. Geben Sie einen leeren Wert an, um den Header zu löschen. Beispiel:
https://localhost:5001/people> set header Content-Type
Testen gesicherter Endpunkte
Die HttpRepl unterstützt das Testen von gesicherten Endpunkten auf folgende Weise:
- Über die Standardanmeldeinformationen des angemeldeten Benutzers.
- Über die Verwendung von HTTP-Anforderungsheadern.
Standardanmeldeinformationen
Angenommen, Sie testen eine Web-API, die in IIS gehostet und durch Windows-Authentifizierung gesichert wird. Sie möchten, dass die Anmeldeinformationen des Benutzers, der das Tool ausführt, an die zu testenden HTTP-Endpunkte übergeben werden. So übergeben Sie die Standardanmeldeinformationen des angemeldeten Benutzers:
Legen Sie die Einstellung
httpClient.useDefaultCredentialsauftruefest:pref set httpClient.useDefaultCredentials trueBeenden und starten Sie das Tool dann neu, bevor Sie eine weitere Anforderung an die Web-API senden.
Standard-Proxyanmeldeinformationen
Stellen Sie sich ein Szenario vor, in dem sich die zu testende Web-API hinter einem Proxy befindet, der durch Windows-Authentifizierung gesichert wird. Sie möchten, dass die Anmeldeinformationen des Benutzers, der das Tool ausführt, an den Proxy übergeben werden. So übergeben Sie die Standardanmeldeinformationen des angemeldeten Benutzers:
Legen Sie die Einstellung
httpClient.proxy.useDefaultCredentialsauftruefest:pref set httpClient.proxy.useDefaultCredentials trueBeenden und starten Sie das Tool dann neu, bevor Sie eine weitere Anforderung an die Web-API senden.
HTTP-Anforderungsheader
Beispiele für unterstützte Authentifizierungs- und Autorisierungsschemas:
- basic authentication
- JWT-Bearertoken
- Digestauthentifizierung
Beispielsweise können Sie mit dem folgenden Befehl ein Bearertoken an einen Endpunkt senden:
set header Authorization "bearer <TOKEN VALUE>"
Um auf einen in Azure gehosteten Endpunkt zuzugreifen oder die Azure-REST-API zu verwenden, benötigen Sie ein Bearertoken. Führen Sie die folgenden Schritte aus, um über die Azure CLI ein Bearertoken für Ihr Azure-Abonnement zu erhalten. Die HttpRepl legt das Bearertoken in einem HTTP-Anforderungsheader fest. Eine Liste mit Azure App Service-Web-Apps wird abgerufen.
Melden Sie sich bei Azure an:
az loginRufen Sie Ihre Abonnement-ID mit dem folgenden Befehl ab:
az account show --query idKopieren Sie Ihre Abonnement-ID, und führen Sie den folgenden Befehl aus:
az account set --subscription "<SUBSCRIPTION ID>"Rufen Sie Ihr Bearertoken mit dem folgenden Befehl ab:
az account get-access-token --query accessTokenStellen Sie über HttpRepl eine Verbindung mit der Azure-REST-API her:
httprepl https://management.azure.comLegen Sie den HTTP-Anforderungsheader
Authorizationfest:https://management.azure.com/> set header Authorization "bearer <ACCESS TOKEN>"Navigieren Sie zum Abonnement:
https://management.azure.com/> cd subscriptions/<SUBSCRIPTION ID>Rufen Sie eine Liste der Azure App Service-Web-Apps Ihres Abonnements ab:
https://management.azure.com/subscriptions/{SUBSCRIPTION ID}> get providers/Microsoft.Web/sites?api-version=2016-08-01Die folgende Antwort wird angezeigt:
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> ] }
Umschalten der Anzeige von HTTP-Anforderungen
Standardmäßig wird die Anzeige der gesendeten HTTP-Anforderung unterdrückt. Sie können die entsprechende Einstellung für die Dauer der Befehlsshellsitzung ändern.
Aktivieren der Anzeige von Anforderungen
Zeigen Sie die gesendete HTTP-Anforderung an, indem Sie den Befehl echo on ausführen. Beispiel:
https://localhost:5001/people> echo on
Request echoing is on
Nachfolgende HTTP-Anforderungen in der aktuellen Sitzung zeigen die Anforderungsheader an. Beispiel:
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>
Deaktivieren der Anzeige von Anforderungen
Unterdrücken Sie die Anzeige der gesendeten HTTP-Anforderung, indem Sie den Befehl echo off ausführen. Beispiel:
https://localhost:5001/people> echo off
Request echoing is off
Ausführen eines Skripts
Wenn Sie häufig die gleichen HttpRepl-Befehle ausführen, können Sie diese in einer Textdatei speichern. Befehle in der Datei nehmen das gleiche Format wie manuell in der Befehlszeile ausgeführte Befehle an. Die Befehle können mithilfe des Befehls run auf einmal ausgeführt werden. Beispiel:
Erstellen Sie eine Textdatei, die einige Befehle enthält, die jeweils in einer neuen Zeile stehen. Sie können die Datei people-script.txt, die folgende Befehle enthält, als Beispiel verwenden:
set base https://localhost:5001 ls cd People ls get 1Führen Sie den Befehl
runaus, und übergeben Sie den Pfad der Textdatei. Beispiel:https://localhost:5001/> run C:\http-repl-scripts\people-script.txtDie folgende Ausgabe wird angezeigt:
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>
Löschen der Ausgabe
Sie können alle Ausgaben des HttpRepl-Tools aus der Befehlsshell entfernen, indem Sie den Befehl clear oder cls ausführen. Nehmen Sie beispielsweise an, dass die Befehlsshell folgende Ausgabe enthält:
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/>
Führen Sie den folgenden Befehl aus, um die Ausgabe zu löschen:
https://localhost:5001/> clear
Nachdem der vorherige Befehl ausgeführt wurde, enthält die Befehlsshell nur die folgende Ausgabe:
https://localhost:5001/>
Zusätzliche Ressourcen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für