どちらも本体内のサーバーにデータを送信しているように見えますが、何が違うのでしょうか?
19 に答える
HTTP PUT:
PUTは、ファイルまたはリソースを特定のURIに、正確にそのURIに配置します。そのURIにすでにファイルまたはリソースがある場合、PUTはそのファイルまたはリソースを置き換えます。そこにファイルまたはリソースがない場合、PUTはそれを作成します。PUTはべき等ですが、逆説的にPUT応答はキャッシュできません。
HTTP POST:
POSTはデータを特定のURIに送信し、そのURIのリソースがリクエストを処理することを期待します。この時点で、Webサーバーは、指定されたリソースのコンテキストでデータをどのように処理するかを決定できます。POSTメソッドはべき等ではありませんが、サーバーが適切なCache-ControlヘッダーとExpiresヘッダーを設定している限り、POST応答はキャッシュ可能です。
公式のHTTPRFCは、POSTを次のように指定しています。
- 既存のリソースの注釈。
- 掲示板、ニュースグループ、メーリングリスト、または同様の記事のグループにメッセージを投稿する。
- フォームの送信結果などのデータのブロックをデータ処理プロセスに提供する。
- 追加操作によるデータベースの拡張。
POSTとPUTの違い:
RFC自体がコアの違いを説明しています。
POSTリクエストとPUTリクエストの基本的な違いは、Request-URIの異なる意味に反映されています。POSTリクエストのURIは、囲まれたエンティティを処理するリソースを識別します。そのリソースは、データ受け入れプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる別のエンティティである可能性があります。対照的に、PUTリクエストのURIは、リクエストで囲まれたエンティティを識別します。ユーザーエージェントは、どのURIが意図されているかを知っており、サーバーはリクエストを他のリソースに適用しようとしてはなりません。サーバーがリクエストを別のURIに適用することを希望する場合、サーバーは301(永続的に移動)応答を送信する必要があります。次に、ユーザーエージェントは、リクエストをリダイレクトするかどうかに関して独自の決定を行うことができます。
さらに、もう少し簡潔に、RFC7231セクション4.3.4PUTの状態(強調を追加)、
4.3.4。置く
PUTメソッドは、ターゲットリソースの状態が 、要求メッセージペイロードで囲まれた表現によって定義された状態である
created
か、その状態であることを要求します。replaced
適切な方法を使用して、関係のないことは別として:
REST ROAとSOAPの利点の1つは、HTTP REST ROAを使用するときに、HTTP動詞/メソッドの適切な使用を促進することです。したがって、たとえば、その正確な場所にリソースを作成する場合にのみPUTを使用します。また、GETを使用してリソースを作成または変更することは決してありません。
セマンティクスのみ。
HTTPPUT
はリクエストの本文を受け入れ、URIで識別されるリソースにそれを保存することになっています。
HTTPPOST
はより一般的です。サーバー上でアクションを開始することになっています。そのアクションは、URIで識別されるリソースにリクエスト本文を格納すること、別のURI、または別のアクションである可能性があります。
PUTはファイルのアップロードのようなものです。URIへの書き込みは、まさにそのURIに影響します。URIへのPOSTは、まったく影響を与える可能性があります。
REST スタイルのリソースの例を挙げるには:
POST /books
一連の書籍情報を使用して新しい書籍を作成し、その書籍を識別する新しい URL で応答する場合があります: /books/5
.
PUT /books/5
ID 5 の新しい本を作成するか、既存の本を ID 5 に置き換える必要があります。
リソース以外のスタイルでPOST
は、副作用のあるほぼすべてのものに使用できます。もう 1 つの違いは、PUT
冪等であることPUTs
です。同じデータを同じ URL に複数送信しても問題ありませんが、複数のデータを送信するとPOSTs
複数のオブジェクトが作成されたり、POST
アクションが何を行ってもかまいません。
PUT は、特定の URI に何かを「アップロード」する方法、またはその URI に既にあるものを上書きする方法を意味します。
一方、POST は、特定の URI に関連するデータを送信する方法です。
HTTP RFCを参照してください
私の知る限り、PUT は主にレコードの更新に使用されます。
POST - ドキュメントまたはその他のリソースを作成する
PUT - 作成されたドキュメントまたはその他のリソースを更新します。
しかし、そのPUTを明確にするために、通常、既存のレコードが存在する場合はそれを「置換」し、存在しない場合は作成します..
POST
他の人はすでに優れた回答を投稿しています。私は、ほとんどの言語、フレームワーク、およびユースケースで、よりもはるかに頻繁にそれを追加したいと思いましたPUT
。PUT, DELETE,
等は基本的に雑学クイズになるところまで。
参照してください: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
最近、POST を使用してリソースを作成し、PUT を使用してリソースを更新/変更するという、Web 開発者の間でよくある誤解にかなり悩まされています。
RFC 2616 の 55 ページ (「Hypertext Transfer Protocol – HTTP/1.1」) のセクション 9.6 (「PUT」) を見ると、PUT が実際に何を目的としているかがわかります。
PUT メソッドは、囲まれたエンティティが指定された Request-URI の下に格納されることを要求します。
POST と PUT の違いを説明する便利な段落もあります。
POST 要求と PUT 要求の根本的な違いは、Request-URI の異なる意味に反映されています。POST 要求の URI は、含まれるエンティティを処理するリソースを識別します。そのリソースは、データを受け入れるプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる別のエンティティである可能性があります。対照的に、PUT リクエストの URI は、リクエストに含まれるエンティティを識別します。ユーザー エージェントは、意図されている URI を認識しており、サーバーはリクエストを他のリソースに適用しようとしてはなりません (MUST NOT)。
更新と作成の違いについては何も言及していません。それはそれが目的ではないからです。これは、次の違いについてです。
obj.set_attribute(value) # A POST request.
この:
obj.attribute = value # A PUT request.
ですから、この一般的な誤解が広まるのを止めてください。RFC を読んでください。
POSTは、ファクトリタイプのメソッドのようなものと見なされます。あなたはあなたが望むものを作成するためにそれにデータを含めます、そして反対側にあるものは何でもそれをどうするかを知っています。PUTは、特定のURLで既存のデータを更新するため、またはURIがどうなるかがわかっていて、まだ存在していない場合に新しいものを作成するために使用されます(何かを作成してURLを返すPOSTとは対照的です)必要に応じて)。
PUT と POST はどちらも Rest メソッドです。
PUT - 同じパラメーターを使用して PUT を使用して同じリクエストを 2 回行った場合、2 回目のリクエストは何の効果もありません。これが、PUT が一般に Update シナリオで使用される理由です。同じパラメーターで Update を複数回呼び出しても、最初の呼び出し以上のことは何も行わないため、PUT はべき等です。
POST はべき等ではありません。たとえば、Create はターゲットに 2 つの別個のエントリを作成するため、べき等ではないため、CREATE は POST で広く使用されています。
毎回同じパラメーターで POST を使用して同じ呼び出しを行うと、2 つの異なることが発生するため、作成シナリオで POST が一般的に使用される理由