PUTおよびDELETEHTTPリクエストメソッドの有用性は何ですか？

Question 1

私はこれについてたくさんのことを読みましたが、このトピックについて結論を出すことができません。

しかし、私はPUTまたはDELETEHTTPリクエストメソッドを使用したことがありません。私の傾向は、システム（私のアプリケーションまたはWebサイト）の統計が影響を受けない場合（製品リストなど）にGETを使用し、影響を受ける場合（発注）にPOSTを使用することです。それで十分ではありませんか、それとも何かが足りませんか？

Question 2

DELETEは、リクエストリソースを削除するためのものです。

DELETEメソッドは、オリジンサーバーがRequest-URIで識別されるリソースを削除することを要求します。このメソッドは、オリジンサーバーへの人間の介入（または他の手段）によってオーバーライドされる場合があります。オリジンサーバーから返されたステータスコードがアクションが正常に完了したことを示していても、クライアントは操作が実行されたことを保証できません…

PUTは、サーバー上のリソースを配置または更新するためのものです。

PUTメソッドは、囲まれたエンティティが指定されたRequest-URIの下に格納されることを要求します。Request-URIが既存のリソースを参照している場合、囲まれたエンティティは、オリジンサーバーに存在するエンティティの変更バージョンと見なされる必要があります。Request-URIが既存のリソースを指しておらず、そのURIが要求元のユーザーエージェントによって新しいリソースとして定義できる場合、オリジンサーバーはそのURIを使用してリソースを作成できます…

完全な仕様については、以下をご覧ください。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

残念ながら、現在のブラウザはHTMLフォームのPOSTとGET以外の動詞をサポートしていないため、通常、HTTPを最大限に活用することはできません（ただし、JavaScriptを介して送信をハイジャックすることはできます）。HTMLフォームでこれらのメソッドがサポートされていないため、たとえば、動詞を含むURIが作成されました。

POST http://example.com/order/1/delete

さらに悪いことに

POST http://example.com/deleteOrder/id/1

HTTPを介してCRUDセマンティクスを効果的にトンネリングします。しかし、動詞はURIの一部になることを意図したものではありませんでした。代わりに、HTTPは、HTTPメソッドを介してリソース（注文など）をCRUDするためのメカニズムとセマンティクスをすでに提供しています。HTTPはプロトコルであり、単なるデータトンネリングサービスではありません。

したがって、Webサーバー上のリソースを削除するには、

DELETE http://example.com/order/1

それを更新するには、

PUT http://example.com/order/1

そして、Webサーバーが適用するために、更新されたリソース表現をPUT本体に提供します。

したがって、REST API用のある種のクライアントを構築している場合は、PUTおよびDELETE要求を送信するようにする可能性があります。これは、JavaScriptを介してリクエストを送信するなど、ブラウザ内に構築されたクライアントの場合もあれば、サーバー上で実行されているツールの場合もあります。

詳細については、以下をご覧ください。

Question 3

GET、POST、DELETE、PUTなどのHTTPリクエスト動詞を使用すると、RESTfulWebアプリケーションを構築できます。ここでそれについて読んでください：http：//en.wikipedia.org/wiki/Representational_state_transfer

これによるメリットを確認する最も簡単な方法は、この例を確認することです。すべてのMVCフレームワークには、Router/DispatcherURLをactionControllersにマップするがあります。したがって、次のようなURL/blog/article/1が呼び出されblogController::articleAction($id); ます。これで、このルーターはURLのみを認識します。/blog/article/1/

ただし、そのルーターがURLだけでなくHTTPリクエストオブジェクト全体を認識している場合は、HTTPリクエスト動詞（GET、POST、PUT、DELETE ...）や、現在のHTTPリクエストに関するその他の多くの便利な機能にアクセスできます。

これにより、アプリケーションを構成して、同じURLを受け入れ、HTTPリクエスト動詞に応じて異なるactionControllerにマップできるようになります。

例えば：

記事1を取得したい場合は、次のようにすることができます。

GET /blog/article/1 HTTP/1.1

ただし、記事1を削除する場合は、次のようにします。

DELETE /blog/article/1 HTTP/1.1

両方のHTTPリクエストが同じURI / blog / article / 1を持っていることに注意してください。唯一の違いは、HTTPリクエスト動詞です。そして、その動詞に基づいて、ルーターはさまざまなactionControllerを呼び出すことができます。これにより、きちんとしたURLを作成できます。

この2つの記事を読んでください、彼らはあなたを助けるかもしれません：

Symfony2-HTTPの基礎

symfony2-ルーティング

これらの記事はSymfony2フレームワークに関するものですが、HTTP要求と応答がどのように機能するかを理解するのに役立ちます。

お役に立てれば！

Question 4

私は人気がないというリスクを冒していますが、最近は役に立たないと言っています。

たとえば、DELETEがサーバーに提供されたURLで見つかったリソースを削除するように指示し、PUT（その兄弟PATCHを含む）がサーバーにべき等な方法で更新を行うように指示したとき、それらは過去によく意図されて有用だったと思います。

物事は進化し、URLは仮想化され（たとえば、URLの書き換えを参照）、リソースは実際のフォルダー/サブフォーダー/ファイルの最初の意味を失い、HTTPプロトコルメソッド（GET、POST、PUT / PATCH、DELETE）でカバーされるCRUDアクション動詞は追跡できなくなりました。

例を見てみましょう：

/ api / entity / list / {id} vs GET / api / entity / {id}
/ api / entity / add / {id} vs POST / api / entity
/ api / entity / edit / {id} vs PUT / api / entity / {id}
/ api / entity / delete / {id} vs DELETE / api / entity / {id}

左側にはHTTPメソッドが記述されておらず、基本的には問題ではなく（POSTとGETで十分です）、右側には適切なHTTPメソッドが使用されています。

右側はエレガントで清潔でプロフェッショナルに見えます。ここで、エレガントなAPIを使用しているコードを維持し、削除呼び出しが行われる場所を検索する必要があると想像してください。「api / entity」を検索し、結果の中からどれがDELETEを実行しているかを確認する必要があります。さらに悪いことに、あなたはジュニアプログラマーがいて、誤ってPUTをDELETEに切り替えてしまい、URLが同じように起こったのです。

私の意見では、アクション動詞をURLに入れることは、それほどエレガントでなくても、そのアクションに適切なHTTPメソッドを使用するよりも利点があります。削除呼び出しが行われた場所を確認したい場合は、「api / entity / delete」を検索するだけで、すぐに見つけることができます。

メソッドのHTTP配列全体を使用せずにAPIを構築すると、後で消費および保守しやすくなります

Question 5

安全な方法：リソースの取得/リソースの変更なし
べき等：何度も要求されてもリソースのステータスは変更されません
安全でない方法：リソースの作成または更新/リソースの変更
非べき等：何度も要求された場合はリソースのステータスが変更されます

あなたの要件に応じて：

1）安全でべき等の操作（リソースのフェッチ）には--------- GETメソッドを使用します
2）安全ではないべき等の操作（リソースの挿入）には--------- POSTメソッドを使用します
3）安全でないべき等操作（リソースの更新）の使用--------- PUTメソッド
3）安全でないべき等操作（リソースの削除）の使用--------- DELETEメソッド