Scott Hanselman

A command-line REPL for RESTful HTTP Services

September 25, '18 Comments [10] Posted in DotNetCore | Open Source
Sponsored By

HTTP REPLMy that's a lot of acronyms. REPL means "Read Evaluate Print Loop." You know how you can run "python" and then just type 2+2 and get answer? That's a type of REPL.

The ASP.NET Core team is building a REPL that lets you explore and interact with your RESTful services. Ideally your services will have Swagger/OpenAPI available that describes the service. Right now this Http-REPL is just being developed and they're aiming to release it as a .NET Core Global Tool in .NET Core 2.2.

You can install global tools like this:

dotnet tool install -g nyancat

Then you can run "nyancat." Get a list of installed tools like this:

C:\Users\scott> dotnet tool list -g
Package Id                 Version                   Commands
--------------------------------------------------------------------
altcover.global            3.5.560                   altcover
dotnet-depends             0.1.0                     dotnet-depends
dotnet-httprepl            2.2.0-preview3-35304      dotnet-httprepl
dotnet-outdated            2.0.0                     dotnet-outdated
dotnet-search              1.0.0                     dotnet-search
dotnet-serve               1.0.0                     dotnet-serve
git-status-cli             1.0.0                     git-status
github-issues-cli          1.0.0                     ghi
nukeeper                   0.7.2                     NuKeeper
nyancat                    1.0.0                     nyancat
project2015to2017.cli      1.8.1                     csproj-to-2017

For the HTTP-REPL, since it's not yet released you have to point the Tool Feed to a daily build location, so do this:

dotnet tool install -g --version 2.2.0-* --add-source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json dotnet-httprepl

Then run it with "dotnet httprepl." I'd like another name? What do you think? RESTy? POSTr? API Test? API View?

Here's an example run where I start up a Web API.

C:\SwaggerApp> dotnet httprepl
(Disconnected)~ set base http://localhost:65369
Using swagger metadata from http://localhost:65369/swagger/v1/swagger.json

http://localhost:65369/~ dir
.        []
People   [get|post]
Values   [get|post]

http://localhost:65369/~ cd People
/People    [get|post]

http://localhost:65369/People~ dir
.      [get|post]
..     []
{id}   [get]

http://localhost:65369/People~ get
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Wed, 26 Sep 2018 20:25:37 GMT
Server: Kestrel
Transfer-Encoding: chunked

[
  {
    "id": 1,
    "name": "Scott Hunter"
  },
  {
    "id": 0,
    "name": "Scott Hanselman"
  },
  {
    "id": 2,
    "name": "Scott Guthrie"
  }
]

Take a moment and read that. It can be a little confusing. It's not HTTPie, it's not Curl, but it's also not PostMan. it's something that you run and stay running if you're a command line person and enjoy that space. It's as if you "cd (change directory)" and "mount" a disk into your Web API.

You can use all the HTTP Verbs, and when POSTing you can set a default text editor and it will launch the editor with the JSON written for you! Give it a try!

A few gotchas/known issues:

  • You'll want to set a default Content-Type Header for your session. I think this should be default.
    • set header Content-Type application/json
  • If the HTTP REPL doesn't automatically detect your Swagger/OpenAPI endpoint, you'll need to set it manually:
    • set base https://yourapi/api/v1/
    • set swagger https://yourapi/swagger.json
  • I haven't figure out how to get it to use VS Code as its default editor. Likely because "code.exe" isn't a thing. (It uses a batch .cmd file, which the HTTP REPL would need to special case). For now, use an editor that's an EXE and point the HTTP REPL like this:
    • pref set editor.command.default 'c:\notepad2.exe'

I'm really enjoy this idea. I'm curious how you find it and how you'd see it being used. Sound off in the comments.


Sponsor: Rider 2018.2 is here! Publishing to IIS, Docker support in the debugger, built-in spell checking, MacBook Touch Bar support, full C# 7.3 support, advanced Unity support, and more.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Wednesday, 26 September 2018 22:46:34 UTC
It might be a better fit as a PowerShell Provider. It's a cool experiment but I feel like it's more shell/navigation than REPL.
Wednesday, 26 September 2018 23:59:53 UTC
It's as if you "cd (change directory)" and "mount" a disk into your Web API.

Imagine actually mounting the Web API to some directory/mount point with a FUSE driver built on this … 🤔
Thursday, 27 September 2018 00:54:23 UTC
This is great, but I must admit I had the same thought as Travis. I often use Invoke-RestMethod in PowerShell for exploring REST APIs but this article made me think how cool it would be to have a proper PowerShell Provider for it as well.
Lachlan Picking
Thursday, 27 September 2018 01:50:17 UTC
I tried using VS Code from the command line.

It is located at \AppData\Local\Programs\Microsoft VS Code and you can just put the full path after `code.exe`
Andrew McClenaghan
Thursday, 27 September 2018 10:48:21 UTC
To go even further with Travis's comment, this seems like a good fit:

Simple Hierarchy in PowerShell (SHiPS) - [ https://github.com/PowerShell/SHiPS ]

Here's the opening description:
A PowerShell provider allows any data store to be exposed like a file system as if it were a mounted drive. In other words, the data in your data store can be treated like files and directories so that a user can navigate data via cd or dir. SHiPS is a PowerShell provider. To be more precise it's a provider utility that simplifies developing PowerShell providers.


I'm not advocating to go with one or the other, but I did find it interesting and thought it would be advantageous for the two teams to work together on the Http REPL.
Michael Tyson
Thursday, 27 September 2018 11:07:59 UTC
'hrep' for name, easy to memorize because of 'href' and just 4 letters...
Roland Halbaksz
Thursday, 27 September 2018 20:52:08 UTC
Scott, here are few naming ideas:

API Pong
REST Checker
RESTer
Larry
Matt Wuertz
Saturday, 29 September 2018 15:13:19 UTC
This is an awesome idea. I'd love to use this for a HAL-style api (https://en.wikipedia.org/wiki/Hypertext_Application_Language)
then you could list out the rel links and follow them. You could do things like "self", "next", "prev", "first", "last" and navigate automatically.
Saturday, 29 September 2018 20:40:57 UTC
Hehe I struggled with vscode as well, also ended up using notepad++ - the "what's new in 2.2" video miss that detail as well. I'll try Andrew's suggestion
Morten Meisler
Sunday, 30 September 2018 14:52:15 UTC
Ever heard of https://github.com/eliangcs/http-prompt in Python?
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.