回答:
HTTP PUT：
PUTは、ファイルまたはリソースを特定のURIに、正確にはそのURIに配置します。そのURIに既にファイルまたはリソースがある場合、PUTはそのファイルまたはリソースを置き換えます。そこにファイルまたはリソースがない場合、PUTはそれを作成します。PUTはべき等ですが、逆説的にPUT応答はキャッシュできません。
HTTP POST：
POSTは特定のURIにデータを送信し、そのURIのリソースがリクエストを処理することを期待します。この時点でのWebサーバーは、指定されたリソースのコンテキストでデータをどう処理するかを決定できます。POSTメソッドはべき等ではありませんが、サーバーが適切なCache-ControlおよびExpiresヘッダーを設定している限り、POST応答はキャッシュ可能です。
公式のHTTP RFCは、POSTを次のように指定しています。
POSTとPUTの違い：
RFC自体がコアの違いを説明しています。
POST要求とPUT要求の基本的な違いは、Request-URIの異なる意味に反映されています。POSTリクエストのURIは、囲まれたエンティティを処理するリソースを識別します。そのリソースは、データを受け入れるプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる個別のエンティティである可能性があります。対照的に、PUTリクエストのURIは、リクエストに含まれるエンティティを識別します。ユーザーエージェントは、意図するURIを認識しており、サーバーは他のリソースへのリクエストの適用を試みてはいけません。サーバーが要求を別のURIに適用することを望む場合、サーバーは301（永久に移動）応答を送信する必要があります。次に、ユーザーエージェントは、リクエストをリダイレクトするかどうかについて独自の決定を行うことができます。
さらに、もう少し簡潔に説明すると、RFC 7231のセクション4.3.4 PUTには次のように記載されています（強調が追加されています）。
4.3.4。プット
PUTメソッドは、ターゲットリソースの状態が、要求メッセージのペイロードで囲まれた表現によって定義された状態である
createdかreplaced、またはその状態で定義されていることを要求します。
適切な方法を使用して、無関係なことはさておき：
REST ROAとSOAPの利点の1つは、HTTP REST ROAを使用するときに、HTTP動詞/メソッドの適切な使用を促進することです。したがって、たとえば、その正確な場所にリソースを作成する場合にのみ、PUTを使用します。また、GETを使用してリソースを作成または変更することは決してありません。
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI。したがって、存在しない場合にリソースの作成を拒否するPUTの実装は正しいでしょう。もしそうなら、これは実際に起こりますか？または、実装は通常PUTでも作成されますか？
セマンティクスのみ。
HTTP PUTは要求の本文を受け入れ、URIで識別されるリソースにそれを格納することになっています。
HTTP POSTはより一般的です。サーバーでアクションを開始することになっています。そのアクションは、URIで識別されたリソースにリクエスト本文を格納することである場合もあれば、別のURIである場合もあれば、別のアクションである場合もあります。
PUTはファイルのアップロードに似ています。URIへの書き込みは、そのURIに正確に影響します。URIへのPOSTは、まったく影響を与えません。
RESTスタイルのリソースの例を示すには：
大量の書籍情報を含む「POST / books」は、新しい書籍を作成し、その書籍を識別する新しいURL「/ books / 5」で応答する場合があります。
"PUT / books / 5"は、IDが5の新しい本を作成するか、既存の本をID 5で置き換える必要があります。
非リソーススタイルでは、POSTは副作用のあるほぼすべてのものに使用できます。もう1つの違いは、PUTはべき等である必要があるということです。同じデータの同じURLへの複数のPUTは問題ないはずです。
私の知る限り、PUTは主にレコードの更新に使用されます。
POST-ドキュメントまたはその他のリソースを作成するには
PUT-作成されたドキュメントまたはその他のリソースを更新します。
しかし、そのPUTを明確にするために、通常、既存のレコードが存在する場合は「置き換え」、存在しない場合は作成します。
他のユーザーはすでに優れた回答を投稿しています。ほとんどの言語、フレームワーク、およびPUTよりもはるかに頻繁にPOSTを処理するユースケースでそれを追加したかっただけです。PUT、DELETEなどが基本的に雑学クイズになるところまで。
ご覧ください：http : //zacharyvoase.com/2009/07/03/http-post-put-diff/
私は最近、POSTを使用してリソースを作成し、PUTを使用してリソースを更新/変更するという、Web開発者による一般的な誤解にかなり悩まされています。
RFC 2616（「ハイパーテキスト転送プロトコル-HTTP / 1.1」）のセクション 55、セクション9.6（「PUT」）を見ると、PUTの実際の目的がわかります。
PUTメソッドは、囲まれたエンティティが指定されたRequest-URIに格納されることを要求します。
POSTとPUTの違いを説明する便利な段落もあります。
POST要求とPUT要求の基本的な違いは、Request-URIの異なる意味に反映されています。POSTリクエストのURIは、囲まれたエンティティを処理するリソースを識別します。そのリソースは、データ受け入れプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる個別のエンティティである可能性があります。対照的に、PUTリクエストのURIは、リクエストで囲まれたエンティティを識別します。ユーザーエージェントは意図されているURIを認識しており、サーバーはリクエストを他のリソースに適用してはなりません。
更新と作成の違いについては何も触れられていません。それはこれの間の違いについてです：
obj.set_attribute(value) # A POST request.
この：
obj.attribute = value # A PUT request.
だから、この人気の誤解の広がりを止めてください。RFCを読んでください。
RESTは、HTTPメソッドを明示的に、プロトコルの定義と整合性のある方法で使用するよう開発者に求めます。この基本的なREST設計原則は、作成、読み取り、更新、削除（CRUD）操作とHTTPメソッドの間の1対1のマッピングを確立します。このマッピングによると：
•サーバーにリソースを作成するには、POSTを使用します。
•リソースを取得するには、GETを使用します。
•リソースの状態を変更または更新するには、PUTを使用します。
•リソースを削除または削除するには、DELETEを使用します。
どちらを使用するかは非常に簡単なはずですが、複雑な表現は多くの人にとって混乱の元になります。
PUTすでにリソースコレクションの一部である単一のリソースを変更する場合に使用します。PUTリソース全体を置き換えます。例：PUT /resources/:resourceId
補足：PATCHリソースの一部を更新する場合に使用します。
POSTリソースのコレクションの下に子リソースを追加する場合に使用します。POST => /resourcesPUTします。POSTします。GET / company / reports => すべてのレポートを取得
GET / company / reports / {id} => 「id」で識別されるレポート情報を取得
POST / company / reports => 新しいレポートを作成
PUT / company / reports / {id} => 更新「id」で識別されるレポート情報
PATCH / company / reports / {id} => 「id」で識別されるレポート情報の一部を更新
DELETE / company / reports / {id} => 「id」でレポートを削除
POSTとPUTの違いは、PUTがべき等であることです。つまり、同じPUT要求を複数回呼び出すと、常に同じ結果が得られます（つまり、副作用はありません）。一方、POST要求を繰り返し呼び出すと、（追加）同じリソースを複数回作成することの副作用。
GET ：GETを使用したリクエストはデータのみを取得します。つまり、指定されたリソースの表現をリクエストします
POST：サーバーにデータを送信してリソースを作成します。リクエストの本文のタイプは、Content-Typeヘッダーで示されます。多くの場合、サーバーに状態の変化や副作用が発生します
PUT ：新しいリソースを作成するか、ターゲットリソースの表現をリクエストペイロードで置き換えます
PATCH ：リソースに部分的な変更を適用するために使用されます
DELETE ：指定されたリソースを削除します
TRACE ：ターゲットリソースへのパスに沿ってメッセージループバックテストを実行し、有用なデバッグメカニズムを提供します
OPTIONS ：ターゲットリソースの通信オプションを説明するために使用されます。クライアントは、OPTIONSメソッドのURL、またはサーバー全体を参照するアスタリスク（*）を指定できます。
HEAD ：GETリクエストと同じレスポンスを要求しますが、レスポンスボディはありません
CONNECT ：ターゲットリソースによって識別されるサーバーへのトンネルを確立し、SSL（HTTPS）を使用するWebサイトへのアクセスに使用できます
RESTフル使用
POST 新しいリソースを作成するために使用され、リソースを返します URI
EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
この呼び出しは新しい本を作成し、その本を返す場合があります URI
Response ...THE-NEW-RESOURCE-URI/books/5
PUT リソースを置き換えるために使用されます。そのリソースが存在する場合は単に更新しますが、そのリソースが存在しない場合は作成します。
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
ではPUT、私たちのリソース識別子を知っているが、POST新しいリソース識別子を返します。
REST以外の使用法
POST サーバー側でアクションを開始するために使用されます。このアクションはリソースを作成する場合と作成しない場合がありますが、このアクションは常に影響を及ぼし、サーバー上の何かを変更します
PUT 特定のURLでリテラルコンテンツを配置または置換するために使用されます
RESTフルスタイルと非RESTフルスタイルの別の違い
POST 非べき等操作です。同じリクエストで複数回実行すると、一部の変更が発生します。
PUT べき等演算です。同じリクエストで複数回実行しても、副作用はありません。
それは言及する価値になりPOST、いくつかの共通の対象となるクロスサイトリクエストフォージェリ（CSRF）攻撃ながらPUTではありません。
以下のCSRFは、被害者が訪問したPUT場合には不可能attackersite.comです。
攻撃の効果があることである被害者が意図せずにユーザーを削除して（被害者）がログインしてたからといってadmin上target.site.com、お出かけになる前にattackersite.com：
通常のリクエスト（Cookieが送信されます）：（PUTはサポートされている属性値ではありません）
上のコードattackersite.com：
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
<input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>
XHRリクエスト（Cookieが送信されます）：（PUTプリフライトリクエストがトリガーされ、そのレスポンスによりブラウザーがdeleteUserページをリクエストできなくなります）
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
実は彼らの肩書き以外に違いはありません。実際、GETと他の基本的な違いがあります。「GET」リクエストメソッドを使用すると、最初に疑問符で区切られ、次に＆記号で区切られたurl-address-lineでデータを送信します。
ただし、「POST」リクエストメソッドでは、URLを介してデータを渡すことはできませんが、データをリクエストのいわゆる「本体」でオブジェクトとして渡す必要があります。サーバー側では、送信されたデータを取得するために、受信したコンテンツの本文を読み取る必要があります。しかし、反対に、「GET」リクエストを送信するときに、本文のコンテンツを送信する可能性はありません。
「GET」はデータを取得するためだけであり、「POST」はデータを投稿するためのものであるという主張は完全に間違っています。「GET」リクエストまたは「POST」リクエストによって送信されたデータに基づいて、新しいコンテンツの作成、既存のコンテンツの削除、既存のコンテンツの編集、またはバックエンドでのあらゆる操作を阻止することはできません。そして、「POST」リクエストを使用してクライアントがデータを要求するような方法でバックエンドをコーディングすることを妨げることはできません。
リクエストでは、使用するメソッドに関係なく、URLを呼び出して、指定するデータを送信するか送信せず、リクエストに対処するためにサーバーに渡す情報を送信します。その後、クライアントはサーバー。データには、送信したいものを何でも含めることができ、バックエンドはデータを使用して何でも実行でき、応答には、そこに入れたい情報を含めることができます。
これらの2つの基本的な方法しかありません。GETおよびPOST。しかし、それはそれらの構造であり、バックエンドでコーディングするものとは異なります。バックエンドでは、受信したデータを使用して、好きなようにコーディングできます。ただし、「POST」リクエストでは、url-addresslineではなく、本文でデータを送信/取得する必要があります。また、「GET」リクエストでは、url-addresslineではなく、url-addresslineでデータを送信/取得する必要があります。体。それで全部です。
「PUT」、「DELETE」などの他のすべてのメソッドは、「POST」と同じ構造です。
コンテンツを多少非表示にしたい場合は、POSTメソッドが主に使用されます。これは、url-addresslineに書き込んだものは何でもキャッシュに保存され、GET-Methodはデータでurl-addresslineを書き込むのと同じであるためです。したがって、必ずしもユーザー名とパスワードであるとは限らない機密データを送信する場合は、たとえば、url-address-lineに表示したくない一部のIDまたはハッシュを送信する場合は、POSTメソッドを使用する必要があります。 。
また、URL-Addresslineの長さは1024記号に制限されていますが、「POST」メソッドは制限されていません。そのため、大量のデータがある場合、GET-Requestでデータを送信できない可能性がありますが、POST-Requestを使用する必要があります。したがって、これはPOSTリクエストのもう1つのプラスポイントでもあります。
ただし、複雑なテキストを送信する必要がない場合は、GET要求を処理する方がはるかに簡単です。それ以外の場合、これはPOSTメソッドのもう1つの利点です。つまり、GETメソッドでは、テキスト内のいくつかの記号やスペースを送信できるようにするために、テキストをURLエンコードする必要があります。ただし、POSTメソッドを使用すると、制限がなくなり、コンテンツを変更したり操作したりする必要がありません。
PUTとPOSTはどちらもRestメソッドです。
PUT-同じパラメーターを使用するPUTを使用して同じ要求を2回行う場合、2番目の要求は効果がありません。これが、PUTが一般的に更新シナリオで使用される理由です。同じパラメーターでUpdateを複数回呼び出しても、最初の呼び出し以外は何も実行されないため、PUTはべき等です。
POSTはべき等ではありません。たとえば、Createはターゲットに2つの個別のエントリを作成するため、べき等ではないため、CREATEはPOSTで広く使用されます。
毎回同じパラメーターでPOSTを使用して同じ呼び出しを行うと、2つの異なることが発生するため、作成シナリオでPOSTが一般的に使用される理由