1. Online Swagger Ui
  2. Download Swagger Ui For Mac Shortcut
  3. Install Swagger Ui
  4. Download Swagger Ui For Windows
  5. Swagger Editor
  6. Swagger Ui Tutorial
-->

By Scott Addie

The HTTP Read-Eval-Print Loop (REPL) is:

  • A lightweight, cross-platform command-line tool that's supported everywhere .NET Core is supported.
  • Used for making HTTP requests to test ASP.NET Core web APIs (and non-ASP.NET Core web APIs) and view their results.
  • Capable of testing web APIs hosted in any environment, including localhost and Azure App Service.

The following HTTP verbs are supported:

To follow along, view or download the sample ASP.NET Core web API (how to download).

  1. Nov 28, 2016.
  2. Download Swagger UI. The Swagger UI is an open source project to visually render documentation for an API defined with the OpenAPI (Swagger) Specification. Swagger UI lets you visualize and interact with the API’s resources without having any of the implementation logic in place, making it easy for back end implementation and client side.

The Swagger Editor is an open source editor to design, define and document RESTful APIs in the Swagger Specification. Swagger Editor can be run locally or accessed on the Web. SwaggerHub brings the Swagger Editor, UI, and Codegen tools to the cloud in an integrated API design and documentation, built for API teams working with the Swagger. 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 ` for more detail on an individual command. Dependency Free The UI works in any development environment, be it locally or in the web Human Friendly Allow end developers to effortlessly interact and try out every single operation your API exposes for easy consumption Easy to Navigate Quickly find and work with resources and endpoints with neatly categorized documentation All Browser Support Cater to every possible scenario with Swagger.

Prerequisites

Installation

To install the HTTP REPL, run the following command:

A .NET Core Global Tool is installed from the Microsoft.dotnet-httprepl NuGet package.

Usage

After successful installation of the tool, run the following command to start the HTTP REPL:

To view the available HTTP REPL commands, run one of the following commands:

The following output is displayed:

The HTTP REPL offers command completion. Pressing the Tab key iterates through the list of commands that complete the characters or API endpoint that you typed. The following sections outline the available CLI commands.

Connect to the web API

Connect to a web API by running the following command:

<ROOT URI> is the base URI for the web API. For example:

Alternatively, run the following command at any time while the HTTP REPL is running:

For example:

Manually point to the Swagger document for the web API

The connect command above will attempt to find the Swagger document automatically. If for some reason it is unable to do so, you can specify the URI of the Swagger document for the web API by using the --swagger option:

For example:

Navigate the web API

View available endpoints

To list the different endpoints (controllers) at the current path of the web API address, run the ls or dir command:

The following output format is displayed:

The preceding output indicates that there are two controllers available: Fruits and People. Both controllers support parameterless HTTP GET and POST operations.

Navigating into a specific controller reveals more detail. For example, the following command's output shows the Fruits controller also supports HTTP GET, PUT, and DELETE operations. Each of these operations expects an id parameter in the route:

Alternatively, run the ui command to open the web API's Swagger UI page in a browser. For example:

Navigate to an endpoint

To navigate to a different endpoint on the web API, run the cd command:

The path following the cd command is case insensitive. The following output format is displayed:

Customize the HTTP REPL

The HTTP REPL's default colors can be customized. Additionally, a default text editor can be defined. The HTTP REPL preferences are persisted across the current session and are honored in future sessions. Once modified, the preferences are stored in the following file:

%HOME%/.httpreplprefs

%HOME%/.httpreplprefs

%USERPROFILE%.httpreplprefs

The .httpreplprefs file is loaded on startup and not monitored for changes at runtime. Manual modifications to the file take effect only after restarting the tool.

View the settings

To view the available settings, run the pref get command. For example:

The preceding command displays the available key-value pairs:

Set color preferences

Response colorization is currently supported for JSON only. To customize the default HTTP REPL tool coloring, locate the key corresponding to the color to be changed. For instructions on how to find the keys, see the View the settings section. For example, change the colors.json key value from Green to White as follows:

Only the allowed colors may be used. Subsequent HTTP requests display output with the new coloring.

When specific color keys aren't set, more generic keys are considered. To demonstrate this fallback behavior, consider the following example:

  • If colors.json.name doesn't have a value, colors.json.string is used.
  • If colors.json.string doesn't have a value, colors.json.literal is used.
  • If colors.json.literal doesn't have a value, colors.json is used.
  • If colors.json doesn't have a value, the command shell's default text color (AllowedColors.None) is used.

Set indentation size

Response indentation size customization is currently supported for JSON only. The default size is two spaces. For example:

To change the default size, set the formatting.json.indentSize key. For example, to always use four spaces:

Subsequent responses honor the setting of four spaces:

Set the default text editor

Download Swagger Ui For Mac

By default, the HTTP REPL has no text editor configured for use. To test web API methods requiring an HTTP request body, a default text editor must be set. The HTTP REPL tool launches the configured text editor for the sole purpose of composing the request body. Run the following command to set your preferred text editor as the default:

In the preceding command, <EXECUTABLE> is the full path to the text editor's executable file. For example, run the following command to set Visual Studio Code as the default text editor:

To launch the default text editor with specific CLI arguments, set the editor.command.default.arguments key. For example, assume Visual Studio Code is the default text editor and that you always want the HTTP REPL to open Visual Studio Code in a new session with extensions disabled. Run the following command:

Set the Swagger search paths

By default, the HTTP REPL has a set of relative paths that it uses to find the Swagger document when executing the connect command without the --swagger option. These relative paths are combined with the root and base paths specified in the connect command. The default relative paths are:

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

To use a different set of search paths in your environment, set the swagger.searchPaths preference. The value must be a pipe-delimited list of relative paths. For example:

Test HTTP GET requests

Synopsis

Arguments

PARAMETER

The route parameter, if any, expected by the associated controller action method.

Options

The following options are available for the get command:

  • -F --no-formatting

    A flag whose presence suppresses HTTP response formatting.

  • -h --header

    Sets an HTTP request header. The following two value formats are supported:

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

    Specifies a file to which the entire HTTP response (including headers and body) should be written. For example, --response 'C:response.txt'. The file is created if it doesn't exist.

  • --response:body

    Specifies a file to which the HTTP response body should be written. For example, --response:body 'C:response.json'. The file is created if it doesn't exist.

  • --response:headers

    Specifies a file to which the HTTP response headers should be written. For example, --response:headers 'C:response.txt'. The file is created if it doesn't exist.

  • -s --streaming

    A flag whose presence enables streaming of the HTTP response.

Example

To issue an HTTP GET request:

  1. Run the get command on an endpoint that supports it:

    The preceding command displays the following output format:

  2. Retrieve a specific record by passing a parameter to the get command:

    The preceding command displays the following output format:

Test HTTP POST requests

Synopsis

Arguments

PARAMETER

The route parameter, if any, expected by the associated controller action method.

Options

  • -F --no-formatting

    A flag whose presence suppresses HTTP response formatting.

  • -h --header

    Sets an HTTP request header. The following two value formats are supported:

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

    Specifies a file to which the entire HTTP response (including headers and body) should be written. For example, --response 'C:response.txt'. The file is created if it doesn't exist.

  • --response:body

    Specifies a file to which the HTTP response body should be written. For example, --response:body 'C:response.json'. The file is created if it doesn't exist.

  • --response:headers

    Specifies a file to which the HTTP response headers should be written. For example, --response:headers 'C:response.txt'. The file is created if it doesn't exist.

  • -s --streaming

    A flag whose presence enables streaming of the HTTP response.

  • -c --content

    Provides an inline HTTP request body. For example, -c '{'id':2,'name':'Cherry'}'.

  • -f --file

    Provides a path to a file containing the HTTP request body. For example, -f 'C:request.json'.

  • --no-body

    Indicates that no HTTP request body is needed.

Example

To issue an HTTP POST request:

  1. Run the post command on an endpoint that supports it:

    Download Android File Transfer to your computer. Remove the USB wall charger adapter from your phone charger, leaving just the USB charging cable. Connect your phone to your computer’s USB port via the charging cable. Open Mac Finder. Locate Android File Transfer on your list of drives. Double-click the Android drive icon. Connect the Android to the Mac Plug your smartphone (which needs to be switched on and unlocked) into the Mac using a USB cable. (If you haven't got the right cable - particularly likely if you've. Download android phone to mac.

    In the preceding command, the Content-Type HTTP request header is set to indicate a request body media type of JSON. The default text editor opens a .tmp file with a JSON template representing the HTTP request body. For example:

    Tip

    To set the default text editor, see the Set the default text editor section.

  2. Modify the JSON template to satisfy model validation requirements:

  3. Save the .tmp file, and close the text editor. The following output appears in the command shell:

Test HTTP PUT requests

Synopsis

Arguments

PARAMETER

The route parameter, if any, expected by the associated controller action method.

Options

  • -F --no-formatting

    A flag whose presence suppresses HTTP response formatting.

  • -h --header

    Sets an HTTP request header. The following two value formats are supported:

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

    Specifies a file to which the entire HTTP response (including headers and body) should be written. For example, --response 'C:response.txt'. The file is created if it doesn't exist.

  • --response:body

    Specifies a file to which the HTTP response body should be written. For example, --response:body 'C:response.json'. The file is created if it doesn't exist.

  • --response:headers

    Specifies a file to which the HTTP response headers should be written. For example, --response:headers 'C:response.txt'. The file is created if it doesn't exist.

  • -s --streaming

    A flag whose presence enables streaming of the HTTP response.

  • -c --content

    Provides an inline HTTP request body. For example, -c '{'id':2,'name':'Cherry'}'.

  • -f --file

    Provides a path to a file containing the HTTP request body. For example, -f 'C:request.json'.

  • --no-body

    Indicates that no HTTP request body is needed.

Example

To issue an HTTP PUT request:

  1. Optional: Run the get command to view the data before modifying it:

  2. Run the put command on an endpoint that supports it:

    In the preceding command, the Content-Type HTTP request header is set to indicate a request body media type of JSON. The default text editor opens a .tmp file with a JSON template representing the HTTP request body. For example:

    Tip

    To set the default text editor, see the Set the default text editor section.

  3. Modify the JSON template to satisfy model validation requirements:

  4. Save the .tmp file, and close the text editor. The following output appears in the command shell:

  5. Optional: Issue a get command to see the modifications. For example, if you typed 'Cherry' in the text editor, a get returns the following:

Test HTTP DELETE requests

Synopsis

Arguments

PARAMETER

The route parameter, if any, expected by the associated controller action method.

Options

  • -F --no-formatting

    A flag whose presence suppresses HTTP response formatting.

  • -h --header

    Sets an HTTP request header. The following two value formats are supported:

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

    Specifies a file to which the entire HTTP response (including headers and body) should be written. For example, --response 'C:response.txt'. The file is created if it doesn't exist.

  • --response:body

    Specifies a file to which the HTTP response body should be written. For example, --response:body 'C:response.json'. The file is created if it doesn't exist.

  • --response:headers

    Specifies a file to which the HTTP response headers should be written. For example, --response:headers 'C:response.txt'. The file is created if it doesn't exist.

  • -s --streaming

    A flag whose presence enables streaming of the HTTP response.

Example

To issue an HTTP DELETE request:

  1. Optional: Run the get command to view the data before modifying it:

  2. Run the delete command on an endpoint that supports it:

    The preceding command displays the following output format:

  3. Optional: Issue a get command to see the modifications. In this example, a get returns the following:

Test HTTP PATCH requests

Synopsis

Arguments

PARAMETER

The route parameter, if any, expected by the associated controller action method.

Options

Online Swagger Ui

  • -F --no-formatting

    A flag whose presence suppresses HTTP response formatting.

  • -h --header

    Sets an HTTP request header. The following two value formats are supported:

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

    Specifies a file to which the entire HTTP response (including headers and body) should be written. For example, --response 'C:response.txt'. The file is created if it doesn't exist.

  • --response:body

    Specifies a file to which the HTTP response body should be written. For example, --response:body 'C:response.json'. The file is created if it doesn't exist.

  • --response:headers

    Specifies a file to which the HTTP response headers should be written. For example, --response:headers 'C:response.txt'. The file is created if it doesn't exist.

  • -s --streaming

    A flag whose presence enables streaming of the HTTP response.

  • -c --content

    Provides an inline HTTP request body. For example, -c '{'id':2,'name':'Cherry'}'.

  • -f --file

    Provides a path to a file containing the HTTP request body. For example, -f 'C:request.json'.

  • --no-body

    Indicates that no HTTP request body is needed.

Test HTTP HEAD requests

Synopsis

Arguments

PARAMETER

The route parameter, if any, expected by the associated controller action method.

Options

  • -F --no-formatting

    A flag whose presence suppresses HTTP response formatting.

  • -h --header

    Sets an HTTP request header. The following two value formats are supported:

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

    Specifies a file to which the entire HTTP response (including headers and body) should be written. For example, --response 'C:response.txt'. The file is created if it doesn't exist.

  • --response:body

    Specifies a file to which the HTTP response body should be written. For example, --response:body 'C:response.json'. The file is created if it doesn't exist.

  • --response:headers

    Specifies a file to which the HTTP response headers should be written. For example, --response:headers 'C:response.txt'. The file is created if it doesn't exist.

  • -s --streaming

    A flag whose presence enables streaming of the HTTP response.

Test HTTP OPTIONS requests

Synopsis

Arguments

PARAMETER

The route parameter, if any, expected by the associated controller action method.

Options

  • -F --no-formatting

    A flag whose presence suppresses HTTP response formatting.

  • -h --header

    Sets an HTTP request header. The following two value formats are supported:

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

    Specifies a file to which the entire HTTP response (including headers and body) should be written. For example, --response 'C:response.txt'. The file is created if it doesn't exist.

  • --response:body

    Specifies a file to which the HTTP response body should be written. For example, --response:body 'C:response.json'. The file is created if it doesn't exist.

  • --response:headers

    Specifies a file to which the HTTP response headers should be written. For example, --response:headers 'C:response.txt'. The file is created if it doesn't exist.

  • -s --streaming

    A flag whose presence enables streaming of the HTTP response.

Set HTTP request headers

To set an HTTP request header, use one of the following approaches:

  • Set inline with the HTTP request. For example:

    With the preceding approach, each distinct HTTP request header requires its own -h option.

  • Set before sending the HTTP request. For example:

    When setting the header before sending a request, the header remains set for the duration of the command shell session. To clear the header, provide an empty value. For example:

Test secured endpoints

The HTTP REPL supports the testing of secured endpoints in two ways: via the default credentials of the logged in user or through the use of HTTP request headers.

Download Swagger Ui For Mac Shortcut

Default credentials

Consider a scenario in which the web API you're testing is hosted in IIS and is secured with Windows authentication. You want the credentials of the user running the tool to flow across to the HTTP endpoints being tested. To pass the default credentials of the logged in user:

Install Swagger Ui

  1. Set the httpClient.useDefaultCredentials preference to true:

  2. Exit and restart the tool before sending another request to the web API.

HTTP request headers

Examples of supported authentication and authorization schemes include basic authentication, JWT bearer tokens, and digest authentication. For example, you can send a bearer token to an endpoint with the following command:

To access an Azure-hosted endpoint or to use the Azure REST API, you need a bearer token. Use the following steps to obtain a bearer token for your Azure subscription via the Azure CLI. The HTTP REPL sets the bearer token in an HTTP request header and retrieves a list of Azure App Service Web Apps.

  1. Log in to Azure:

  2. Get your subscription ID with the following command:

  3. Copy your subscription ID and run the following command:

  4. Get your bearer token with the following command:

  5. Connect to the Azure REST API via the HTTP REPL:

  6. Set the Authorization HTTP request header:

  7. Navigate to the subscription:

  8. Get a list of your subscription's Azure App Service Web Apps:

    The following response is displayed:

Toggle HTTP request display

By default, display of the HTTP request being sent is suppressed. It's possible to change the corresponding setting for the duration of the command shell session.

Enable request display

View the HTTP request being sent by running the echo on command. For example:

Subsequent HTTP requests in the current session display the request headers. For example:

Disable request display

Download Swagger Ui For Windows

Suppress display of the HTTP request being sent by running the echo off command. For example:

Run a script

Swagger Editor

If you frequently execute the same set of HTTP REPL commands, consider storing them in a text file. Commands in the file take the same form as those executed manually on the command line. The commands can be executed in a batched fashion using the run command. For example:

  1. Create a text file containing a set of newline-delimited commands. To illustrate, consider a people-script.txt file containing the following commands:

  2. Execute the run command, passing in the text file's path. For example:

    The following output appears:

Clear the output

To remove all output written to the command shell by the HTTP REPL tool, run the clear or cls command. To illustrate, imagine the command shell contains the following output:

Run the following command to clear the output:

After running the preceding command, the command shell contains only the following output:

Swagger Ui Tutorial

Additional resources