REST Webサービスでアクションをトリガーするには、どのHTTP動詞を使用する必要がありますか？

RESTful Webサービスを実装していますが、利用可能なアクションの1つはになりますreload。設定、キャッシュなどを再ロードするために使用されます。

GETこのような単純なURIから始めました${path}/cache/reload（パラメーターは渡されず、URIのみが呼び出されます）。GETリクエストでデータを変更しないでください。

RESTful Webサービスでアクション/コマンドを呼び出すために使用する正しい動詞はどれですか？

リロードは、独自のキャッシュ/構成/などをリロードするREST Webサービスのコマンドです。クライアントに情報を返すメソッドではありません。

おそらく私がやろうとしていることはRESTではありませんが、それでもこの方法で行う必要があるものです。このreloadメソッドは、アプリケーションの範囲内で意味のある実際の例に過ぎず、ほとんどの回答はそれに焦点を当てていますが、実際には、CRUDを実行しないがデータ/データを変更するアクションをトリガーする動詞を知る必要がありました状態。

Stack Overflowでこの詳細な回答を見つけました。件名：https ://stackoverflow.com/questions/16877968/

このトランザクションは実際には「RESTful」ではないため、このアクションに適切な動詞はないと思います。「s」と「t」は「状態転送」を表し、ここでは何も転送されていません。または、別の言い方をすれば、最も厳密な定義により、PUTやPOSTなどの動詞は常に名詞とともに使用され、「リロード」は動詞のみを持ちます。

このリロードはRESTfulではないかもしれませんが、それでも有用である可能性があり、それを行う方法を選択して、それが異常であるかどうかを説明します。GETはおそらく最も簡単です。ただし、コメントにはかなりの懐疑心があります。そのため、他の何かが本来の動作をしていないために、このリロードアクションが必要かどうかを検討する必要があります。

RESTfulになりたい場合は、アクションを実行する動詞を考えないでください。クライアントが何かを実行した後のリソースの状態を考えてください。

したがって、上記の例のいずれかを使用すると、電子メールを送信している電子メールキューがあります。クライアントに、その電子メールキューを一時停止または停止などの状態にすることを要求します。

そのため、クライアントはそのリソースの新しい状態をサーバーにPUTします。このJSONのようにシンプルにすることができます

PUT http://myserver.com/services/email_service HTTP/1.1
Content-Type: text/json

{"status":"paused"}

サーバーは、現在のステータス（「実行中」など）から「一時停止」ステータス/状態に到達する方法を見つけ出します。

クライアントがリソースに対してGETを実行すると、現在の状態（「一時停止」など）が返されます。

この方法でこれを行う理由、およびRESTが非常に強力になる理由は、HOWを終了してサーバーをその状態にすることです。

クライアントは「これは現在の状態です」と言うだけで、サーバーはそれを実現する方法を見つけます。データベースの単純なフリップかもしれません。何千ものアクションが必要になる場合があります。クライアントは気にしませんし、知る必要もありません。

したがって、サーバーがそれを行う方法とクライアントが気にしない方法を完全に書き換え/再設計できます。クライアントは、リソースのさまざまな状態（およびそれらの表現）を認識するだけでよく、内部構造を認識する必要はありません。

受け入れられたものを含む他の回答のいくつかは、GETを使用することを勧めています（あまり熱心ではありませんが）。

同意しません。

まず第一に、これは理想的ではなく、実際にはRESTfulではないことを伝える他のすべての人が正しいことです。適切なRESTfulシナリオでは、サーバー上のリソースを操作し、それらのリソースを追加、更新、削除、取得などしています。PUTは、リクエストが完了したときにリソースがどうあるべきかを表すペイロードを送信し、POSTはサーバーに追加されるリソースを表すペイロードを送信する必要があります。また、GETはサーバー上のリソースを返す必要があります。

RPC（リモートプロシージャコール）がありますが、これはRESTfulではありません-サーバー上で何かをしたいです。したがって、純粋にRESTfulなAPIを作成しようとしている場合は、実行していることを再検討する必要があります。

ただし、ルールを少し曲げる必要がある場合もあります。特に、公開されない内部APIを開発している場合、トレードオフに価値があると判断するかもしれません。

その場合、RPC がべき等であるかどうかに応じて、PUTまたはPOSTをお勧めします。

一般に、HTTP PUTはSQL UPDATEにマップされ、HTTP POSTはSQL INSERTにマップされると言いますが、厳密にはそうではありません。より純粋な方法は、HTTP PUTはべき等である必要があり、HTTP POSTはそうである必要はないということです。これは、副作用なしで何度でも同じPUT要求を呼び出すことができることを意味します。一度呼び出したら、再度呼び出しても問題はありません。ただし、意図しない限り、POST要求を繰り返し呼び出すことはできません。各POSTはサーバー上のデータを再び変更します。

あなたの場合、このリロード機能が必要な場合は、UT等のように聞こえるので、PUTをお勧めします。しかし、私はまだ他の人がそれをまったく必要としないと言ったことを検討することをお勧めします。

POSTおよびPUTWebサーバにエンティティを送信するために使用されるHTTP動詞です。を使用するPUTと、送信されたエンティティは、指定されたURIのリソースの（新しい）表現になりますが、これは目的に合っていません。POSTこれは、エンティティがリソースの補助データである従来のフォームハンドラーのためのものであり、それが勝者です。エンティティにはコマンドまたはアクションが含まれます（例： "action = reload"）。

ただし、問題のコマンドはおそらくRESTインターフェースを介して公開すべきではありません。データは他のチャネル（ファイルシステム、DBクライアントなど）を介して変更できるため、「リロード」の必要性が生じたように思えます。キャッシュは透過的でなければなりません。さらに、HTTP要求はアトミックである必要があり、他のチャネルを介して送信されるメッセージも考慮に入れる必要があります。構成設定に「リロード」コマンドを提供することは、不必要な複雑さのようです。それを要求するのは脆い設計です。あるチャネルには会話全体が含まれていないため、別のチャネルを介した更新後にクリーンアップに「リロード」を公開することは汚れています。代わりに、次のいずれかを検討してください。

• 完全にREST経由で更新を行う
• コマンドを他のチャネルに公開する
• アクションを自動化する

これらのオプションの一部は、他の制限が存在するかどうかによっては実行できない場合があります。

「RESTでのPUTとPOST」も参照してください。

クライアントリクエストが明示的にそのようなものを更新するために呼び出しを行う必要があるのはなぜだろうと主張します。それは、GETのより一般的な実装の隠されたロジック（つまり、プルデータですが、プルされる前にサービスがデータを更新する）、またはクライアントから離れたバックエンドの別のトリガーによるもののようです。

結局、data / configは後続の呼び出しで最新である必要があるだけなので、データ更新のための遅延呼び出しと熱心な呼び出しの方がより重要です。明らかに私はここで多くのことを想定していますが、そのような明示的でスタンドアロンの呼び出しの必要性を再評価するために一歩後退します。

アクションをリソースのように扱わないのはなぜですか。キャッシュを更新したいので、システムに新しいアクションをPOSTします。

純粋主義者のために、あなたはそのための専用のURLを持つことができます。これを拡張して、実際のアクションをデータベース（またはストレージ）に日付、ステータス、ユーザーなどとともに記録できることに注意してください。

一般的なシステム全体の操作/ actions / {action}

リソースタイプ/ actions / {resource} / {action}に固有の操作

リソース固有の操作/ actions / {resource} / {id} / {action}

あなたの場合、キャッシュはおそらくシステム全体の/ actions / reload_cacheです

REST Webサービスでアクションをトリガーするには、どのHTTP動詞を使用する必要がありますか？

RESTサービスの詳細を検討するとき、このヒューリスティックを検討することはしばしば有用です：Webサイトでこれをどのように実装しますか？

HTMLは、GETおよびPOST要求のみをネイティブに記述できます。そこで、検索を開始できます。

あるGET適切な？この質問に答えるには、クライアントおよび中間コンポーネントがについて許可されるという仮定について考える必要がありますGET。のセマンティクスGETは安全です

クライアントは、ターゲットリソースに安全なメソッドを適用した結果として、オリジンサーバーの状態の変更を要求せず、予期もしません。同様に、安全な方法を合理的に使用しても、オリジンサーバーに害、財産の損失、または異常な負荷が生じることはありません。

したがって、クライアントと中間コンポーネントは、自分の懸念を満たすために必要な頻度でGET要求を呼び出す裁量権を持っています。スパイダーは無差別にリソースを取得して、インデックスを更新できます。キャッシュはプリフェッチできます。信頼性の低いネットワークでは、失われたメッセージを必要な頻度で再試行して、少なくとも1つの応答を確保できます。

設定、キャッシュなどを再ロードするために使用されます。

これらが高額なものである場合、クライアントが独自の裁量でこれらのリクエストを発行することを望まないかもしれません。

POST一方、実質的に制約はありません。これにより、汎用クライアントが行うことができる仮定が大幅に削減されます。コンポーネントが投機的なPOSTリクエストを行うことはありません。なぜなら、そうするのは間違いだからです。標準ではそれでいいとは言われていません。

PUT、PATCH、DELETE...これらのより具体的なセマンティクスを持つ危険な方法がありますPOST。適切かどうかは、リソースモデルによって異なります。

覚えておくべき重要なアイデアは、HTTPメソッドがドキュメントドメインに属していることです（Jim Webberの2011年のトークを参照）。説明している効果はおそらくドキュメントドメインの一部ではなく、ドキュメントが変更されたときに呼び出される副作用です。これにより、作業を遂行するためにドキュメントを整理する方法に関して、多くの自由が与えられます。