RESTについて考えると、HTTPメソッドをCRUDアクション（作成用のPOST、読み取り用のGETなど）にマッピングするのは比較的簡単です。しかし、「ファイアアンドフォーゲット」アクションについてはどうでしょうか。バッチジョブのトリガー（呼び出し元に応答が返されない）などのファイアアンドフォーゲットアクションを最もよく表すHTTPメソッドはどれですか？
POSTが頭に浮かぶでしょうが、99％の場合、これらのタイプのアクションに一連のパラメーターを提供するだけなので、GETも適切な方法だと思います。どう思いますか？
POST が思い浮かびますが、GET の方が適切な方法だと思います。99% の場合、これらのタイプのアクションには一連のパラメーターしか提供しないからです。どう思いますか？
使用するパラメータの数は、使用する動詞とは何の関係もないと思います。重要な問題は、外部から見える状態を変更しているかどうかです。
あなたの例では、バッチジョブがオブジェクトの外部から見える状態に影響を与えない場合、バッチジョブとして実装できます。ただし、関連するリソース コンテナーを持つリソースとしてバッチ ジョブをモデル化することはできます。
Post を使用して新しい BatchJob リソースを作成し、ユーザーが GET を実行してこれまでのジョブの進行状況を確認できるようにすることができます。リソース コンテナーで GET を実行して、実行中のすべてのバッチ ジョブを一覧表示し、場合によっては DELETE を呼び出して 1 つを強制終了できます。
リクエストがデータを変更する場合は POST を使用し、読み取るだけの場合は GET を使用する必要があります。
あなたのリクエストは「ファイアアンドフォーゲット」なので、データを変更していると思いますので、POSTを使用してください。
一般的なケースでは、さまざまなペイロード パラメータを十分に提供できると思いますが、これらは GET で可能な範囲を超える可能性があるため、POST は非常に合理的です。ジョブを開始するアクションは、GET セマティクスにうまく適合しません。
考えてみると、アクションが実際に応答を返さない可能性があります。
a)。いいえ、それは不可能な要求です。私たちはあなたの仕事を開始できません。b)。わかりました、あなたの職務番号は 93 です。
私は別の視点を提供するために、この質問を死からよみがえらせます。
CORS が普及した現在、API URI を知っている人なら誰でもバッチ ジョブをトリガーできるようにするか ( )、Joe を防ぐためにリクエストの発信元を制限するかのどちらを使用するGETかの選択が問題になります。コンピューターでジョブをトリガーすることはできません ( )。POSTGETPOST
そのレベルに関心がある場合は、おそらく HEAD が必要な HTTP メソッドです。これは GET と同じですが、応答本文が空であるという規定があります。それはあなたが求めているものにぴったりだと思いますか？