`Invoke-RestMethod` & `Invoke-WebRequest` should have tab completion for `-ContentType`

[ArmaanMcleod]

Summary of the new feature / enhancement

As a user who tests API REST calls from the terminal using Invoke-RestMethod & Invoke-WebRequest frequently, it would be very beneficial to have tab completion for content types. Especially for common ones like application/json or application/x-www-form-urlencoded which can get cumbersome to type out every time.

Given the list of MIME Types is quite big and most of these are not commonly used in PowerShell, we could limit tab completion to common content types.

Quick grep search of content types across GitHub repos for PowerShell:

• application/json
• application/x-www-form-urlencoded
• application/xml
• application/zip
• application/octet-stream

We could even use .NET Media MIME types in System.Net.Mime.MediaTypeNames to load these in dynamically and avoid hardcoding a list.

It would improve the developer experience of these cmdlets, especially when testing API calls.

Proposed technical implementation details (optional)

• Add a ContentArgumentCompleter to virtual property ContentType in WebRequestPSCmdlet base class.
• Ensure user can do something like Invoke-RestMethod -ContentType <TAB> and cycle through completions of content types.
• If they provide start of word it would complete the possible content type completions e.g. Invoke-RestMethod -ContentType 'app<TAB> would complete to Invoke-RestMethod -ContentType 'application/json'.

[jhoneill]

The problem doing this is trying to make the set of options complete

It is tedious typing these, so you can add this to your profile

Register-ArgumentCompleter -CommandName Invoke-RestMethod -ParameterName Contenttype -ScriptBlock { 
  'application/json','application/x-www-form-urlencoded','application/xml', 'application/zip','application/octet-stream' }

[iSazonov]

For discussion https://github.com/dotnet/runtime/blob/c693bfaa3eb6a18c185c315c07621bd0212c5796/src/libraries/System.Net.Mail/src/System/Net/Mime/MediaTypeNames.cs

GitHub

runtime/src/libraries/System.Net.Mail/src/System/Net/Mime/MediaTypeNames.cs at c693bfaa3eb6a18c185c315c07621bd0212c5796 · dotnet/runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps. - dotnet/runtime

[iSazonov]

1. Are there MIME types that don't make sense to use in these cmdlets?

2. Another observation. For a long time, we had a limited list of options for Encoding parameters. (Although now there is a complete list of available encodings.)

3. We could collect the most commonly used types from scripts on GitHub.

[ArmaanMcleod]

1. Are there MIME types that don't make sense to use in these cmdlets?
2. Another observation. For a long time, we had a limited list of options for Encoding parameters. (Although now there is a complete list of available encodings.)
3. We could collect the most commonly used types from scripts on GitHub.

1. IMO MIME types which belong to MediaTypes.Application and MediaTypes.Text make sense. If we had to pick one, I think MediaTypes.Application is the most common and many of the content types I see in GitHub search results.
2. I agree, for encodings this makes sense. We'd probably need to discuss that in another issue.
3. This is doable but I'm not sure is worth the effort. If there is a decision from WG about limiting this to the most used content types, we could trim down the list. It is also tricky to use GitHub as well because many examples in search results don't specify content type in plaintext which is obvious. This exercise seems quite laborious and may not yield significant benefits. Just like understanding all the different content types which are possible which needs discussion and review for each one we add to the list. Only to lead to the possible issue being raised like "Hey Invoke-WebRequest does not tab complete to the content type I want..." 😄. Although this is a risk in any case because there may be strange content types being used in the wild which PowerShell could not cover because it solves the general use case which should be good enough because we pull them directly from .NET.