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

Question

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

Answer 1

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

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

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

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

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

• 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を介してリクエストを送信する場合や、サーバーで実行されているツールである場合などです。

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

• http://martinfowler.com/articles/richardsonMaturityModel.html
• PUT、DELETE、HEADなどのメソッドはほとんどのWebブラウザーで使用できますか？
• HTMLフォームにPUTメソッドとDELETEメソッドがないのはなぜですか
• PUTとDELETEをフォームで使用する必要がありますか？
• http://amundsen.com/examples/put-delete-forms/
• http://www.quora.com/HTTP/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms

Answer 2

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リクエストとレスポンスがどのように機能するかを理解するのに役立ちます。

お役に立てれば！

Answer 3

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

たとえば、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を構築すると、後で消費および保守しやすくなります

Answer 4

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

要件に応じて：

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

Answer 5

@Gordonから受け入れられた回答を参照してください。重要な点は、次のとおりです。

PUTとDELETEは意味のある特定の動詞であり、サーバーに特定のことを実行するように指示し、命令の処理方法を指示します。

OKの標準とセマンティクスは素晴らしいですが、データベースから何かを削除するためにコードを実行するだけの場合、DELETEは実際にどのように使用されますか？

したがって、「OKですが、パスを持つURIにGETを発行することで、削除を行う方が簡単です/api/entity/delete/{id}（@Bogdanの回答で提案されています）。OKでは、GETの定義を見てみましょう。

GETメソッドは、Request-URIによって識別された情報（エンティティの形式）を取得することを意味します

ソース-W3C標準-https: //www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

に使用GETするDELETE場合は、標準の定義に従ってメソッドを明らかに誤用しています。

/api/entity/delete/{id}さて、さらに「OK」と言いましょう。ただし、開発者にとっては、GETと同じ署名を持つリソースを削除するDELETEメソッドを使用する代わりに、GETメソッドを使用して読み取るURIをどこかで読み取る方が実用的であるため、実際には問題ではありません。取得するメソッド。これにより、開発者はそれが削除を目的としていることを理解できます。適切に構造化されたDELETEメソッドの署名について考えてみましょう（例は.NET Core 5の場合です）。

// DELETE: api/TodoItems/5
[HttpDelete("{id}")]
public async Task<IActionResult> DeleteTodoItem(long id)
{

これはgetリクエストに応答しません（たとえば、APIを呼び出すときに取得するのではなく、誤って削除する方が保護されます。開発者はAPIに対して明示的にDELETEリクエストを実行する必要があります）。また、非常に明確で、構造化され、名前が付けられたAPI操作があり、開発者や自動化されたツールでも明確で高度に検出できます（たとえば、開発者はDELETE、コード内の出現箇所を具体的に検索したり、DELETEを明確に示すメソッド名を検索したりできます。 ）。さらに、このパターンは、「RESTFUL」APIの一般的に受け入れられている標準に準拠しており、開発者（および場合によっては自動化されたツール）がAPIをより広く認識して解釈できるようにする必要があります。

OK、それはいいのですが、それをDELETEにすることの本当の違いは何ですか？なぜGETの代わりにDELETEを使用するのですか？私の操作はデータベースから何かを削除していますが、なぜ私のWebサーバーは気にする必要がありますか？OK、DELETEの定義について考えてみましょう。

9.7 DELETE-DELETEメソッドは、オリジンサーバーがRequest-URIで識別されるリソースを削除するように要求します。このメソッドは、オリジンサーバーでの人間の介入（または他の手段）によってオーバーライドされる場合があります。

したがって、削除を指定している場合、サーバー上で特定の動作が発生する可能性があり、手動または自動の介入によって削除アクションを元に戻すことができる可能性があります。特定のユースケースでは、それは重要である可能性があります。

さて、DELETEは私にとってはうまくいきますが、なぜPUTを使用するのですか？たとえば、POSTを使用する「upsert」メソッドを作成し、リソースが存在する場合は更新し、存在しない場合は作成すると便利です。

私は通常、データベースに対する操作に影響を与えるAPIを実装するときにこれを行いますが、PUTには特定の意味があります。つまり、リソースの更新を具体的に示し、POSTは作成を示すため、作成と更新の両方にPOSTを使用します。私自身の見解では、REST APIは、アップサート機能の実用性が、追加と挿入の正しい動詞の厳密な使用よりも重要であると通常考えている場合ですが、ここで何かが欠けている可能性があります。

REST APIの外部でPUTを使用することは、実用的な目的でより重要になる可能性があります。たとえば、サーバーがリソースが更新されたことを理解することでキャッシュをクリアできる可能性がある更新操作を実行している場合（これは、リソースが更新された場合により重要です）たとえば、ドキュメント全体です）。更新操作のためにPUTをRESTfulAPI内で使用する場合、私が考慮していなかったいくつかの実用的な利点があるかもしれません。

POSTの標準定義では、POST成功応答は一般的な「200OK」だけでなく201（作成）である必要があると規定されているため、リソースの作成が明示的に成功したことを正しく解釈できます。その応答は更新操作には適切ではありませんが、応答コードの標準で「MUST」が指定されていません。開発者がアップサートにPOSTを使用し、作成であろうと更新であろうと、成功すると200（OK）を返すことは確かに一般的です。

PUTの標準はより厳密であり、更新を試みるときにリソースが予期せず作成された場合は、201応答コードを介して示さなければならないことを指定しています。これは、指定されたURIに既存のリソースが存在しない場合に発生する可能性があります。この標準では、PUTを使用すると、試行された更新操作の結果が期待どおりであるかどうかについて、より明確なフィードバックが得られると説明されています。

W3C標準から：

[プット]が既存のリソースを指しておらず、そのURIが要求元のユーザーエージェントによって新しいリソースとして定義できる場合、オリジンサーバーはそのURIを使用してリソースを作成できます。新しいリソースが作成された場合、オリジンサーバーは201（作成済み）応答を介してユーザーエージェントに通知する必要があります。既存のリソースが変更された場合、リクエストが正常に完了したことを示すために、200（OK）または204（コンテンツなし）の応答コードを送信する必要があります。

Answer 6

置く

このPUTメソッドは、リソースを変更する必要がある場合に常に使用されます。すでにリソースコレクションの一部であるリソース。ここで注意すべきことの1つは、PUTメソッドはリソース全体を変更するのに対し、PATCHメソッドはリソースまたはデータの必要な部分を変更するために使用されるということです。

消去

名前が示すように、DELETErequestメソッドは指定されたリソースを削除するために使用されます。オリジンサーバーがRequest-URLで識別されるリソースを削除するように要求します。

この簡単な定義がお役に立てば幸いです。