Комментарии
Автор надеется, что вы выбросите Postman

Вот когда автор расскажет, как в его поделке авторизоваться в удаленном сервисе через OAuth 2, или, что веселее, послать запрос, подписанный по требованиям AWS, тогда и поговорим.

Добавлю: вместо Invoke-WebRequest можно использовать Invoke-RestMethod, он за нас умеет делать сериализацию/десериализацию тела запроса/ответа в JSON/XML и обратно в PS-объекты, а еще имеет набор заготовленных параметров для типичных RESTful API.


https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-restmethod?view=powershell-7

Люблю и ненавижу PowerShell. С одной стороны позволяет с легкостью автоматизировать даже сложные процессы, с другой совершенно идиотский и неконсистентный синтаксис с динамической типизацией.
Например, работа с коллекцией через foreach(obj in $list) {...} и через $list | Foreach-Object {...} разнится и зачастую непредсказуемо, если внутри блока использовать continue, break или return или код внутри блока выкидывает исключение.
За двойные стандарты вызова функций авторов PowerShell нужно отправить в несгораемый котел: почему одним функциям нужно передавать параметр через Set-Value -Parameter "Hi", а другим через "string".Split(";")? Эта неконсистентость только усиливается классами, пример которых представлен в статье. Если я объявляю функцию модуля, то она будет вызваться как Get-Something, но если я создаю класс, то это уже ClassInstance.Get($something). Я кучу часов потратил на отладку неработающего кода, из-за того, что скопировал функцию из объявления Invoke-Something($a = "aaa", $b = "bbb) и забыл убрать скобки!
Еще одна болезнь — толерантность к пустым переменным. Я плачу по strict режиму, чтобы нельзя было использовать необъявленные и неинициализированные переменные. Куча времени уходит на поимку фантомов, после того, как в одном месте изменяется название переменной, а ниже по пайпу она продолжает использоваться как ни в чем не бывало. Еще хуже с этим дела обстоят в PowerShell ISE, который будет хранить временное значение переменной до перезапуска, а вы будете себе рвать волосы на голове, не понимая почему значение переменной $MuVar не меняется, хотя выше по коду $MyVar давно имеет новое значение.

После Bash, где написание скриптов подобно заплыву по бездонному океану граблей, PowerShell кажется потрясающе логичным и продуманным.
В добавок к вашему списку еще хочется добавить то как он возвращает значения из функций.
Заголовок спойлера
function testSingleValue{
  "1"
  "2"
  "3"
  return "4"
}
testSingleValue


This function returns the number 4 as a string, right? Wrong! It returns an array with the values “1”,”2”,”3”,”4”. The reason is that the strings “1”,”2” and “3” are not saved into a variable, so the output of those strings goes into the PowerShell pipeline, which collects the outputs of each line and returns all the values as an array.
Потому что в powershell ключевое слово return выполняет другую функцию. Непривычно но не более.
Из документации:

The return keyword exits a function, script, or script block. It can be used to exit a scope at a specific point, to return a value, or to indicate that the end of the scope has been reached.

Users who are familiar with languages like C or C# might want to use the return keyword to make the logic of leaving a scope explicit.

In PowerShell, the results of each statement are returned as output, even without a statement that contains the Return keyword. Languages like C or C# return only the value or values that are specified by the return keyword.
Я плачу по strict режиму
— не понял, есть же Set-StrictMode. Временное значение переменной до перезапуска зависит, скорее всего, не от ISE, а от сессии PS. От сессии PS же зависит загрузка psm-модулей — грузится однократно, а для перезагрузки только завершать сессию.
Первый же код такой вывод про $NewClass.Sum(1, 1):
При создании конвейера произошла ошибка.
+ CategoryInfo: NotSpecified: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId: RuntimeException
То ли у меня лыжи не те, то ли ещё чего, но вообще не представляю как хотябы среднего размера запросы отправлять через командную строку.
Вот нужно в середине JSON в 10 строк поменять пару строк. А после отправки поменять ещё раз. И ещё раз.

Идти файл редактировать каждый раз?
Или в командной строке ковырять мульти-строковую команду?
А выравнивать JSON руками что ли тогда?

Короче куча проблем, которые Postman и ему подобные решают легко.

А зачем строки менять? PowerShell десериализует JSON в объект и достаточно будет поменять свойство нужных полей, а потом сериализовать и отправить ответ:


$Json = @"
{
    "Param1": "",

    "Param2": {
        "Param3": 1,
        "Param4": ["1", "2","3"],
    }
}
"@

$psObject = $Json | ConvertFrom-Json 
$psObject.Param2.Param4[2] = "5"

$psObject | ConvertTo-Json

Причем неважно откуда будет получен исходный объект — прочитан из файла, из запроса или сформирован через переменные PowerShell.

В смысле зачем строки менять? Затем чтобы новый запрос отправить.
Вот пусть я сначала создаю с JSON как у вас, затем второй объект у которого 10 значений в массиве Param4, затем у третьего объекта есть Param5 типа объект с несколькими полей. Который я вставлю из внутренностей ответа на другой запрос.

Причём это мне нужно только сегодня. Это задача на один раз, никакой автоматизации не нужно. Мутить пайплайн который всё это сделает не нужно.

Так вот, как вы будете это делать в командной строке?

Добавлено:
И вот то что вы породили через изменение параметра объекта это угар. Напишу я коллеге: «смотри, чо у нас происходит». А он мне: «интереснько. а ну-ка кинь мне курл». А я что ему?
НЛО прилетело и опубликовало эту надпись здесь

А можно взять LINQPad и писать маленькие скрипты на обычном C#, при этом пользуясь отличным визуализатором. По сравнению с PowerShell визуального мусора на порядок меньше

Окей гугл: как пройтись по всем сайтовым коллекциям SharePoint и почистить в них корзину из LINQPad? Как в несколько шагов организовать миграцию для SQL Server по аналогии с dbatools?
Может для программиста и проще накидать скетч на C#, а для администратора проще написать скрипт на повершеле. Тем более, что управление инфраструктурой Microsoft построено вокруг PowerShell.

Понятное дело, что есть задачи, для которых есть готовое решение только в виде cmdlet'ов. Я скорее про то, что большинство примеров из статьи легко переписать на C#, и при этом код станет короче и менее шумным.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.