Condividi tramite


Testare API Web con HttpRepl

Il ciclo Read-Eval-Print (REPL) HTTP:

  • È un strumento da riga di comando multipiattaforma leggero supportato ovunque sia supportato .NET Core.
  • Consente di eseguire richieste HTTP per testare le API Web ASP.NET Core (e le API Web non ASP.NET Core) e visualizzare i relativi risultati.
  • Riesce a testare le API Web ospitate in qualsiasi ambiente, inclusi localhost e Servizio app di Azure.

Sono supportati i verbi HTTP seguenti:

Per continuare, visualizzare o scaricare l'API Web ASP.NET Core di esempio (come scaricare).

Prerequisiti

Installazione

Per installare HttpRepl, eseguire il comando seguente:

dotnet tool install -g Microsoft.dotnet-httprepl

Viene installato uno strumento globale .NET Core dal pacchetto NuGet Microsoft.dotnet-httprepl.

Nota

Per impostazione predefinita, l'architettura dei file binari .NET da installare rappresenta l'architettura del sistema operativo attualmente in esecuzione. Per specificare un'architettura del sistema operativo diversa, vedere dotnet tool install, --opzione arch.. Per altre informazioni, vedere Problema di GitHub dotnet/AspNetCore.Docs #29262.

In macOS aggiornare il percorso:

export PATH="$HOME/.dotnet/tools:$PATH"

Utilizzo

Dopo aver completato l'installazione dello strumento, eseguire il comando seguente per avviare HttpRepl:

httprepl

Per visualizzare i comandi HttpRepl disponibili, eseguire uno dei comandi seguenti:

httprepl -h
httprepl --help

Verrà visualizzato l'output seguente:

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 il completamento del comando. Premendo il tasto TAB è possibile scorrere l'elenco dei comandi che completano i caratteri o l'endpoint API digitato. Le sezioni seguenti descrivono i comandi dell'interfaccia della riga di comando disponibili.

Connettersi all'API Web

Connettersi all'API Web eseguendo il comando seguente:

httprepl <ROOT URI>

<ROOT URI> è l'URI di base dell'API Web. Ad esempio:

httprepl https://localhost:5001

In alternativa, eseguire il comando seguente in qualsiasi momento mentre è in esecuzione HttpRepl:

connect <ROOT URI>

Ad esempio:

(Disconnected)> connect https://localhost:5001

Puntare manualmente alla descrizione OpenAPI per l'API Web

Il comando connect precedente tenterà di individuare automaticamente la descrizione OpenAPI. Se per qualche motivo l'individuazione non riesce, è possibile specificare l'URI della descrizione OpenAPI per l'API Web usando l'opzione --openapi:

connect <ROOT URI> --openapi <OPENAPI DESCRIPTION ADDRESS>

Ad esempio:

(Disconnected)> connect https://localhost:5001 --openapi /swagger/v1/swagger.json

Abilitare l'output dettagliato per informazioni sulla ricerca, l'analisi e la convalida della descrizione OpenAPI

Se si specifica l'opzione --verbose con il comando connect, verranno generati più dettagli quando lo strumento cerca la descrizione OpenAPI, la analizza e la convalida.

connect <ROOT URI> --verbose

Ad esempio:

(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]

Visualizzare gli endpoint disponibili

Per visualizzare l'elenco dei diversi endpoint (controller) nel percorso corrente dell'indirizzo dell'API Web, eseguire il comando ls o dir:

https://localhost:5001/> ls

Viene visualizzato il formato di output seguente:

.        []
Fruits   [get|post]
People   [get|post]

https://localhost:5001/>

L'output precedente indica che sono disponibili due controller: Fruits e People. Entrambi i controller supportano operazioni HTTP GET e POST senza parametri.

L'esplorazione di un controller specifico offre altri dettagli. Ad esempio, l'output del comando seguente mostra che il controller Fruits supporta anche le operazioni HTTP GET, PUT e DELETE. Ognuna di queste operazioni prevede un parametro id nella route:

https://localhost:5001/fruits> ls
.      [get|post]
..     []
{id}   [get|put|delete]

https://localhost:5001/fruits>

In alternativa, eseguire il comando ui per aprire la pagina dell'interfaccia utente di Swagger dell'API Web in un browser. Ad esempio:

https://localhost:5001/> ui

Per passare a un endpoint diverso nell'API Web, eseguire il comando cd:

https://localhost:5001/> cd people

Nel percorso che segue il comando cd non viene fatta distinzione tra maiuscole e minuscole. Viene visualizzato il formato di output seguente:

/people    [get|post]

https://localhost:5001/people>

Personalizzare HttpRepl

I colori predefiniti di HttpRepl possono essere personalizzati. È anche possibile definire un editor di testo predefinito. Le preferenze di HttpRepl vengono mantenute nella sessione corrente e in quelle future. Dopo essere state modificate, le preferenze vengono archiviate nel file seguente:

%HOME%/.httpreplprefs

Il file con estensione httpreplprefs viene caricato all'avvio e non viene monitorato per le modifiche in fase di esecuzione. Le modifiche manuali apportate al file diventano effettive solo dopo il riavvio dello strumento.

Visualizzare le impostazioni

Per visualizzare le impostazioni disponibili, eseguire il comando pref get. Ad esempio:

https://localhost:5001/> pref get

Il comando precedente visualizza le coppie chiave-valore disponibili:

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

Impostare le preferenze colori

La colorazione delle risposte è attualmente supportata solo per JSON. Per personalizzare la colorazione predefinita dello strumento HttpRepl, individuare la chiave corrispondente al colore da cambiare. Per istruzioni su come trovare le chiavi, vedere la sezione Visualizzare le impostazioni. Ad esempio, modificare il valore della chiave colors.json da Green a White come indicato di seguito:

https://localhost:5001/people> pref set colors.json White

È possibile usare solo i colori consentiti. Output delle richieste HTTP successive con la nuova colorazione.

Quando non sono impostate chiavi di colore specifiche, vengono considerate chiavi più generiche. Per comprendere questo comportamento di fallback, si consideri l'esempio seguente:

  • Se colors.json.name non ha un valore, viene usato colors.json.string.
  • Se colors.json.string non ha un valore, viene usato colors.json.literal.
  • Se colors.json.literal non ha un valore, viene usato colors.json.
  • Se colors.json non ha un valore, viene usato il colore del testo predefinito della shell dei comandi (AllowedColors.None).

Impostare la dimensione del rientro

La personalizzazione della dimensione del rientro delle risposte è attualmente supportata solo per JSON. La dimensione del rientro predefinita è di due spazi. Ad esempio:

[
  {
    "id": 1,
    "name": "Apple"
  },
  {
    "id": 2,
    "name": "Orange"
  },
  {
    "id": 3,
    "name": "Strawberry"
  }
]

Per modificare la dimensione predefinita, impostare la chiave formatting.json.indentSize. Ad esempio, per usare sempre quattro spazi:

pref set formatting.json.indentSize 4

L'impostazione dei quattro spazi viene applicata alle risposte successive:

[
    {
        "id": 1,
        "name": "Apple"
    },
    {
        "id": 2,
        "name": "Orange"
    },
    {
        "id": 3,
        "name": "Strawberry"
    }
]

Impostare l'editor di testo predefinito

Per impostazione predefinita, HttpRepl non ha un editor di testo configurato per l'uso. Per testare i metodi dell'API Web che richiedono un corpo della richiesta HTTP, è necessario impostare un editor di testo predefinito. Lo strumento HttpRepl avvia l'editor di testo configurato al solo scopo di comporre il corpo della richiesta. Eseguire il comando seguente per impostare l'editor di testo preferito come predefinito:

pref set editor.command.default "<EXECUTABLE>"

Nel comando precedente <EXECUTABLE> è il percorso completo del file eseguibile dell'editor di testo. Ad esempio, eseguire il comando seguente per impostare Visual Studio Code come editor di testo predefinito:

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

Per avviare l'editor di testo predefinito con argomenti dell'interfaccia della riga di comando specifici, impostare la chiave editor.command.default.arguments. Si supponga, ad esempio, che Visual Studio Code sia l'editor di testo predefinito e che si voglia HttpRepl apra sempre Visual Studio Code in una nuova sessione con le estensioni disabilitate. Esegui questo comando:

pref set editor.command.default.arguments "--disable-extensions --new-window"

Suggerimento

Se l'editor predefinito è Visual Studio Code, in genere si passa l'argomento -w o --wait per forzare Visual Studio Code ad attendere la chiusura del file prima di tornare.

Impostare i percorsi di ricerca della descrizione OpenAPI

Per impostazione predefinita, HttpRepl ha un set di percorsi relativi che usa per trovare la descrizione OpenAPI quando si esegue il comando connect senza l'opzione --openapi. Questi percorsi relativi vengono combinati con i percorsi radice e di base specificati nel comando connect. I percorsi relativi predefiniti sono i seguenti:

  • swagger.json
  • swagger/v1/swagger.json
  • /swagger.json
  • /swagger/v1/swagger.json
  • openapi.json
  • /openapi.json

Per usare un set di percorsi di ricerca diverso nell'ambiente in uso, impostare la preferenza swagger.searchPaths. Il valore deve essere un elenco di percorsi relativi delimitati da pipe. Ad esempio:

pref set swagger.searchPaths "swagger/v2/swagger.json|swagger/v3/swagger.json"

Invece di sostituire completamente l'elenco predefinito, è anche possibile modificarlo aggiungendo o rimuovendo percorsi.

Per aggiungere uno o più percorsi di ricerca all'elenco predefinito, impostare la preferenza swagger.addToSearchPaths. Il valore deve essere un elenco di percorsi relativi delimitati da pipe. Ad esempio:

pref set swagger.addToSearchPaths "openapi/v2/openapi.json|openapi/v3/openapi.json"

Per rimuovere uno o più percorsi di ricerca dall'elenco predefinito, impostare la preferenza swagger.addToSearchPaths. Il valore deve essere un elenco di percorsi relativi delimitati da pipe. Ad esempio:

pref set swagger.removeFromSearchPaths "swagger.json|/swagger.json"

Testare le richieste HTTP GET

Riepilogo

get <PARAMETER> [-F|--no-formatting] [-h|--header] [--response:body] [--response:headers] [-s|--streaming]

Argomenti

PARAMETER

Parametro di route, se presente, previsto dal metodo di azione del controller associato.

Opzioni

Per il comando get sono disponibili le opzioni seguenti:

  • -F|--no-formatting

    Flag la cui presenza elimina la formattazione della risposta HTTP.

  • -h|--header

    Imposta un'intestazione della richiesta HTTP. Sono supportati i due formati di valore seguenti:

    • {header}={value}
    • {header}:{value}
  • --response:body

    Specifica un file in cui deve essere scritto il corpo della risposta HTTP. Ad esempio: --response:body "C:\response.json". Se il file non esiste, verrà creato.

  • --response:headers

    Specifica un file in cui devono essere scritte le intestazioni della risposta HTTP. Ad esempio: --response:headers "C:\response.txt". Se il file non esiste, verrà creato.

  • -s|--streaming

    Flag la cui presenza abilita il flusso della risposta HTTP.

Esempio

Per inviare una richiesta HTTP GET:

  1. Eseguire il comando get in un endpoint che lo supporta:

    https://localhost:5001/people> get
    

    Il comando precedente visualizza il formato di output seguente:

    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. Recuperare un record specifico passando un parametro al comando get:

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

    Il comando precedente visualizza il formato di output seguente:

    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>
    

Testare le richieste HTTP POST

Riepilogo

post <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]

Argomenti

PARAMETER

Parametro di route, se presente, previsto dal metodo di azione del controller associato.

Opzioni

  • -F|--no-formatting

    Flag la cui presenza elimina la formattazione della risposta HTTP.

  • -h|--header

    Imposta un'intestazione della richiesta HTTP. Sono supportati i due formati di valore seguenti:

    • {header}={value}
    • {header}:{value}
  • --response:body

    Specifica un file in cui deve essere scritto il corpo della risposta HTTP. Ad esempio: --response:body "C:\response.json". Se il file non esiste, verrà creato.

  • --response:headers

    Specifica un file in cui devono essere scritte le intestazioni della risposta HTTP. Ad esempio: --response:headers "C:\response.txt". Se il file non esiste, verrà creato.

  • -s|--streaming

    Flag la cui presenza abilita il flusso della risposta HTTP.

  • -c|--content

    Specifica un corpo della richiesta HTTP inline. Ad esempio: -c "{\"id\":2,\"name\":\"Cherry\"}".

  • -f|--file

    Specifica il percorso di un file contenente il corpo della richiesta HTTP. Ad esempio: -f "C:\request.json".

  • --no-body

    Indica che non è necessario alcun corpo della richiesta HTTP.

Esempio

Per inviare una richiesta HTTP POST:

  1. Eseguire il comando post in un endpoint che lo supporta:

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

    Nel comando precedente l'intestazione della richiesta HTTP Content-Type è impostata per indicare un tipo di supporto del corpo della richiesta JSON. L'editor di testo predefinito apre un file con estensione tmp con un modello JSON che rappresenta il corpo della richiesta HTTP. Ad esempio:

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

    Suggerimento

    Per impostare l'editor di testo predefinito, vedere la sezione Impostare l'editor di testo predefinito.

  2. Modificare il modello JSON per soddisfare i requisiti di convalida del modello:

    {
      "id": 0,
      "name": "Scott Addie"
    }
    
  3. Salvare il file con estensione tmp e chiudere l'editor di testo. Nella shell dei comandi viene visualizzato l'output seguente:

    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>
    

Testare le richieste HTTP PUT

Riepilogo

put <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]

Argomenti

PARAMETER

Parametro di route, se presente, previsto dal metodo di azione del controller associato.

Opzioni

  • -F|--no-formatting

    Flag la cui presenza elimina la formattazione della risposta HTTP.

  • -h|--header

    Imposta un'intestazione della richiesta HTTP. Sono supportati i due formati di valore seguenti:

    • {header}={value}
    • {header}:{value}
  • --response:body

    Specifica un file in cui deve essere scritto il corpo della risposta HTTP. Ad esempio: --response:body "C:\response.json". Se il file non esiste, verrà creato.

  • --response:headers

    Specifica un file in cui devono essere scritte le intestazioni della risposta HTTP. Ad esempio: --response:headers "C:\response.txt". Se il file non esiste, verrà creato.

  • -s|--streaming

    Flag la cui presenza abilita il flusso della risposta HTTP.

  • -c|--content

    Specifica un corpo della richiesta HTTP inline. Ad esempio: -c "{\"id\":2,\"name\":\"Cherry\"}".

  • -f|--file

    Specifica il percorso di un file contenente il corpo della richiesta HTTP. Ad esempio: -f "C:\request.json".

  • --no-body

    Indica che non è necessario alcun corpo della richiesta HTTP.

Esempio

Per inviare una richiesta HTTP PUT:

  1. Facoltativo: eseguire il comando get per visualizzare i dati prima di modificarli:

    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. Eseguire il comando put in un endpoint che lo supporta:

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

    Nel comando precedente l'intestazione della richiesta HTTP Content-Type è impostata per indicare un tipo di supporto del corpo della richiesta JSON. L'editor di testo predefinito apre un file con estensione tmp con un modello JSON che rappresenta il corpo della richiesta HTTP. Ad esempio:

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

    Suggerimento

    Per impostare l'editor di testo predefinito, vedere la sezione Impostare l'editor di testo predefinito.

  3. Modificare il modello JSON per soddisfare i requisiti di convalida del modello:

    {
      "id": 2,
      "name": "Cherry"
    }
    
  4. Salvare il file con estensione tmp e chiudere l'editor di testo. Nella shell dei comandi viene visualizzato l'output seguente:

    [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. Facoltativo: immettere un comando get per visualizzare le modifiche. Ad esempio, se si digita "Cherry" nell'editor di testo, get restituisce l'output seguente:

    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>
    

Testare le richieste HTTP DELETE

Riepilogo

delete <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]

Argomenti

PARAMETER

Parametro di route, se presente, previsto dal metodo di azione del controller associato.

Opzioni

  • -F|--no-formatting

    Flag la cui presenza elimina la formattazione della risposta HTTP.

  • -h|--header

    Imposta un'intestazione della richiesta HTTP. Sono supportati i due formati di valore seguenti:

    • {header}={value}
    • {header}:{value}
  • --response:body

    Specifica un file in cui deve essere scritto il corpo della risposta HTTP. Ad esempio: --response:body "C:\response.json". Se il file non esiste, verrà creato.

  • --response:headers

    Specifica un file in cui devono essere scritte le intestazioni della risposta HTTP. Ad esempio: --response:headers "C:\response.txt". Se il file non esiste, verrà creato.

  • -s|--streaming

    Flag la cui presenza abilita il flusso della risposta HTTP.

Esempio

Per inviare una richiesta HTTP DELETE:

  1. Facoltativo: eseguire il comando get per visualizzare i dati prima di modificarli:

    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. Eseguire il comando delete in un endpoint che lo supporta:

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

    Il comando precedente visualizza il formato di output seguente:

    HTTP/1.1 204 No Content
    Date: Fri, 28 Jun 2019 17:36:42 GMT
    Server: Kestrel
    
  3. Facoltativo: immettere un comando get per visualizzare le modifiche. In questo esempio get restituisce l'output seguente:

    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>
    

Testare le richieste HTTP PATCH

Riepilogo

patch <PARAMETER> [-c|--content] [-f|--file] [-h|--header] [--no-body] [-F|--no-formatting] [--response] [--response:body] [--response:headers] [-s|--streaming]

Argomenti

PARAMETER

Parametro di route, se presente, previsto dal metodo di azione del controller associato.

Opzioni

  • -F|--no-formatting

    Flag la cui presenza elimina la formattazione della risposta HTTP.

  • -h|--header

    Imposta un'intestazione della richiesta HTTP. Sono supportati i due formati di valore seguenti:

    • {header}={value}
    • {header}:{value}
  • --response:body

    Specifica un file in cui deve essere scritto il corpo della risposta HTTP. Ad esempio: --response:body "C:\response.json". Se il file non esiste, verrà creato.

  • --response:headers

    Specifica un file in cui devono essere scritte le intestazioni della risposta HTTP. Ad esempio: --response:headers "C:\response.txt". Se il file non esiste, verrà creato.

  • -s|--streaming

    Flag la cui presenza abilita il flusso della risposta HTTP.

  • -c|--content

    Specifica un corpo della richiesta HTTP inline. Ad esempio: -c "{\"id\":2,\"name\":\"Cherry\"}".

  • -f|--file

    Specifica il percorso di un file contenente il corpo della richiesta HTTP. Ad esempio: -f "C:\request.json".

  • --no-body

    Indica che non è necessario alcun corpo della richiesta HTTP.

Testare le richieste HTTP HEAD

Riepilogo

head <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]

Argomenti

PARAMETER

Parametro di route, se presente, previsto dal metodo di azione del controller associato.

Opzioni

  • -F|--no-formatting

    Flag la cui presenza elimina la formattazione della risposta HTTP.

  • -h|--header

    Imposta un'intestazione della richiesta HTTP. Sono supportati i due formati di valore seguenti:

    • {header}={value}
    • {header}:{value}
  • --response:body

    Specifica un file in cui deve essere scritto il corpo della risposta HTTP. Ad esempio: --response:body "C:\response.json". Se il file non esiste, verrà creato.

  • --response:headers

    Specifica un file in cui devono essere scritte le intestazioni della risposta HTTP. Ad esempio: --response:headers "C:\response.txt". Se il file non esiste, verrà creato.

  • -s|--streaming

    Flag la cui presenza abilita il flusso della risposta HTTP.

Testare le richieste HTTP OPTIONS

Riepilogo

options <PARAMETER> [-F|--no-formatting] [-h|--header] [--response] [--response:body] [--response:headers] [-s|--streaming]

Argomenti

PARAMETER

Parametro di route, se presente, previsto dal metodo di azione del controller associato.

Opzioni

  • -F|--no-formatting

    Flag la cui presenza elimina la formattazione della risposta HTTP.

  • -h|--header

    Imposta un'intestazione della richiesta HTTP. Sono supportati i due formati di valore seguenti:

    • {header}={value}
    • {header}:{value}
  • --response:body

    Specifica un file in cui deve essere scritto il corpo della risposta HTTP. Ad esempio: --response:body "C:\response.json". Se il file non esiste, verrà creato.

  • --response:headers

    Specifica un file in cui devono essere scritte le intestazioni della risposta HTTP. Ad esempio: --response:headers "C:\response.txt". Se il file non esiste, verrà creato.

  • -s|--streaming

    Flag la cui presenza abilita il flusso della risposta HTTP.

Impostare le intestazioni delle richieste HTTP

Per impostare l'intestazione di una richiesta HTTP, usare uno degli approcci seguenti:

  • Impostare inline con la richiesta HTTP. Ad esempio:

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

    Con l'approccio precedente, ogni singola intestazione di richiesta HTTP richiede una propria opzione -h.

  • Impostare prima di inviare la richiesta HTTP. Ad esempio:

    https://localhost:5001/people> set header Content-Type application/json
    

    Quando si imposta l'intestazione prima di inviare una richiesta, l'intestazione rimane impostata per la durata della sessione della shell dei comandi. Per cancellare l'intestazione, specificare un valore vuoto. Ad esempio:

    https://localhost:5001/people> set header Content-Type
    

Testare gli endpoint protetti

HttpRepl supporta il test degli endpoint protetti nei modi seguenti:

  • Tramite le credenziali predefinite dell'utente connesso.
  • Tramite l'uso di intestazioni di richieste HTTP.

Credenziali predefinite

Si consideri un'API Web da testare ospitata in IIS e protetta con l'autenticazione di Windows. Si desidera che le credenziali dell'utente che esegue lo strumento vengano propagate agli endpoint HTTP testati. Per passare le credenziali predefinite dell'utente connesso:

  1. Impostare la preferenza httpClient.useDefaultCredentials su true:

    pref set httpClient.useDefaultCredentials true
    
  2. Chiudere e riavviare lo strumento prima di inviare un'altra richiesta all'API Web.

Credenziali proxy predefinite

Si consideri uno scenario in cui l'API Web da testare si trova dietro un proxy protetto con l'autenticazione di Windows. Si desidera che le credenziali dell'utente che esegue lo strumento vengano propagate al proxy. Per passare le credenziali predefinite dell'utente connesso:

  1. Impostare la preferenza httpClient.proxy.useDefaultCredentials su true:

    pref set httpClient.proxy.useDefaultCredentials true
    
  2. Chiudere e riavviare lo strumento prima di inviare un'altra richiesta all'API Web.

Intestazioni di richiesta HTTP

Gli schemi di autenticazione e autorizzazione supportati includono ad esempio:

  • basic authentication
  • Token di connessione JWT
  • autenticazione digest

Ad esempio, è possibile inviare un token di connessione a un endpoint con il comando seguente:

set header Authorization "bearer <TOKEN VALUE>"

Per accedere a un endpoint ospitato in Azure o per usare l'l'API REST di Azure, è necessario un token di connessione. Seguire questa procedura per ottenere un token di connessione per la sottoscrizione di Azure tramite l'interfaccia della riga di comando di Azure. HttpRepl imposta il token di connessione in un'intestazione di richiesta HTTP. Viene recuperato un elenco di app Web del servizio app di Azure.

  1. Accedere ad Azure:

    az login
    
  2. Ottenere l'ID sottoscrizione con il comando seguente:

    az account show --query id
    
  3. Copiare l'ID sottoscrizione ed eseguire il comando seguente:

    az account set --subscription "<SUBSCRIPTION ID>"
    
  4. Ottenere il token di connessione con il comando seguente:

    az account get-access-token --query accessToken
    
  5. Connettersi all'API REST di Azure tramite HttpRepl:

    httprepl https://management.azure.com
    
  6. Impostare l'intestazione della richiesta HTTP Authorization:

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

    https://management.azure.com/> cd subscriptions/<SUBSCRIPTION ID>
    
  8. Ottenere un elenco di app Web del servizio app di Azure della sottoscrizione:

    https://management.azure.com/subscriptions/{SUBSCRIPTION ID}> get providers/Microsoft.Web/sites?api-version=2016-08-01
    

    Viene visualizzata la risposta seguente:

    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>
      ]
    }
    

Attivare o disattivare la visualizzazione delle richieste HTTP

Per impostazione predefinita, la visualizzazione della richiesta HTTP inviata viene eliminata. È possibile modificare l'impostazione corrispondente per la durata della sessione della shell dei comandi.

Abilitare la visualizzazione delle richieste

Visualizzare la richiesta HTTP inviata eseguendo il comando echo on. Ad esempio:

https://localhost:5001/people> echo on
Request echoing is on

Le richieste HTTP successive della sessione corrente visualizzano le intestazioni delle richieste. Ad esempio:

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>

Disabilitare la visualizzazione delle richieste

Eliminare la visualizzazione della richiesta HTTP inviata eseguendo il comando echo off. Ad esempio:

https://localhost:5001/people> echo off
Request echoing is off

Esegui uno script

Se si esegue spesso lo stesso set di comandi HttpRepl, può essere utile archiviarlo in un file di testo. I comandi nel file hanno lo stesso formato di quelli eseguiti manualmente nella riga di comando. I comandi possono essere eseguiti in modalità batch usando il comando run. Ad esempio:

  1. Creare un file di testo contenente un set di comandi delimitati da una nuova riga. Si consideri ad esempio un file people-script.txt contenente i comandi seguenti:

    set base https://localhost:5001
    ls
    cd People
    ls
    get 1
    
  2. Eseguire il comando run passando il percorso del file di testo. Ad esempio:

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

    Viene visualizzato l'output seguente:

    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>
    

Cancellare l'output

Per rimuovere l'intero output scritto nella shell dei comandi dallo strumento HttpRepl, eseguire il comando clear o cls. Si supponga ad esempio che la shell dei comandi includa l'output seguente:

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

Eseguire il comando seguente per cancellare l'output:

https://localhost:5001/> clear

Dopo aver eseguito il comando precedente, la shell dei comandi contiene solo l'output seguente:

https://localhost:5001/>

Risorse aggiuntive