ブログを作って早々だが、前言を撤回する。ElasticsearchとPowershellは相性が悪い。

前置き

先日、Elasticsearchの操作をPowershellで行うために
REST API をPowershellで扱うための Elasticsearch のススメ(1)、(2)、(3)
という記事を書いたのだけど、根本的にはElasticsearchとPowershell（Invoke-RestMethod）は相性が悪いのでElasticsearchを触りたいという目的の場合にはcurl.exeの利用をお勧めする。
※元々の目的であるInvoke-RestMethodを使用したいという場合には余り影響はない

これはREST APIにおけるGET、POST、PUT、DELETEという各名称（機能）と、そもそもGETとPOSTの違いというHTTPの仕様に起因する話である。
そして、HTTPの仕様で話すならElasticsearchが誤っている。ただ、今後 REST APIが普及するに従って、後追いで拡張される可能性もあるので標準に囚われない仕様が悪いとは必ずしもいえない（それはMSだって通ってきた道）。

追記：search API

あとで知ったのであれだが、この記事は無意味かも。Elasticsearch のsearch APIはGETとPOSTのどちらでも動くので、POSTにしてしまえば支障なく使えます。

https://medium.com/hello-elasticsearch/elasticsearch-api-83760ce1424b

内容と回避策（？）

具体的にいうと、GETメソッドにJSONデータを渡す処理ができないのである。
Kibanaにて検索を掛けるとき、以下のような構文になる。これをInvoke-RestMethodではリクエストすることができない。

GET _search
{
  "query": {
    "match_all": {}
  }
}

最初、該当のリクエストはGETメソッドのお作法に則りURLエンコードして渡す処理なんだろうと勝手に勘違いし、上手く動かないなぁと無駄に時間をかけていた。
それもそのはず、実はPOSTメソッドと同様にデータを送っているのである。気が付いた瞬間はマジかーと思ったし、見当違いなコードを書いていた自分が悲しくなったりもした。

そして暫く放置していたのだが、先人の知恵を借りるべくググってみたところ、以下のブログを発見した。
Learning Elasticsearch with PowerShell

Flaw Workaround

.NET is right. Elasticsearch is wrong. Breaking the rules for the sake of what you personally feel makes you a vigilante. Forcing a square peg into a round hole just for the sake of making sure "gets" are done with GET makes you an extremist. Bodies belong in POST and PUT, not GET.

私が言いたかったことが書いてあった。そして回避策まで提示してくれている。かっこいい！
ただ、リクエストで使っている「source」というJsonを投げるパラメーターがうまく動かない。
記事が2015年のものだし、公式（現時点の最新：6.4）ドキュメントにも載ってないし、現在では廃止された！？
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html

結論

そんな訳で、Invoke-RestMethodでElasticsearchをあれこれするのは諦めることにした。
Powershellで処理したい人は素直にcurl.exeをダウンロードして連携してください。