回答:
Create = PUT with a new URI
POST to a base URI returning a newly created URI
Read = GET
Update = PUT with an existing URI
Delete = DELETE
PUTは、PUTで使用されるURIの存在に応じて、作成と更新の両方にマップできます。
POSTはCreateにマップされます。
修正：POSTは、通常、作成に使用されますが、更新にマップすることもできます。POSTは部分的に更新することもできるため、提案されたPATCHメソッドは必要ありません。
重要なのは、べき等の変更を行っているかどうかです。つまり、メッセージに対して2回アクションを実行した結果、1回だけ実行されたかのように「同じ」ものが存在する場合は、べき等の変更があり、PUTにマップする必要があります。そうでない場合は、POSTにマップされます。クライアントがURLを合成することを決して許可しない場合、PUTはUpdateにかなり近く、POSTはCreateを適切に処理できますが、それが唯一の方法ではありません。クライアントが作成したいこと/foo/abcを知っていて、そこにどのコンテンツを配置するかを知っている場合、PUTとして正常に機能します。
POSTの標準的な説明は、何かを購入しようとしているときです。それは、知らないうちに繰り返したくないアクションです。対照的に、事前に注文の発送先住所を設定することは、PUTを使用して問題なく実行できます。1 6 Anywhere Dr, Nowhereville回、2回、または100回送付するように指示されても、それは同じ住所です。それはアップデートだということですか？かもしれない…それはすべてあなたがバックエンドをどのように書きたいかに依存します。（結果が同一でない可能性があることに注意してください：ユーザーがリソースの表現の一部として最後にPUTを行ったときにユーザーに報告することができます。これにより、繰り返されるPUTが同一の結果を引き起こさないことが保証されますが、結果は依然として機能的な意味で「同じ」であること。）
POSTとPUT興味深いものである、との答えにする必要があります「『作成』とこれが『更新』であるのか？」はるかに明確です。さらに、APIの実装に関しては、繰り返しPUTはサイレントno-opになるPOSTはずですが、送信されるデータの一部の側面がデータストア内で一意のままであると想定される場合、繰り返しは例外をスローする可能性があります。それがアプリケーションを支えています。
現在（2016）の最新のHTTP動詞は、GET、POST、PATCH、PUT、DELETEです。
概観
お役に立てれば！
REST APIの設計に興味がある場合は、これを参考にしてください。ウェブサイトオンライン版 github リポジトリ
実際にこれを説明するstormpathによる素晴らしいyoutubeビデオトークがあります、URLはビデオの正しい部分にスキップする必要があります：
また、1時間以上話し合うのも一見の価値がありますが、REST APIの構築に時間を費やすことを考えている場合は非常に興味深いものです。
具体的な状況にもよりますが、一般的には：
PUT =リソースの具象URIで具象リソースを更新または変更します。
POST = 指定されたURIのソースの下に新しいリソースを作成します。
すなわち
ブログ投稿を編集します。
PUT：/ blog / entry / 1
新しいものを作成します。
POST：/ blog / entry
PUTは、新しいリソースのURIがリクエストの前に明確である状況で、新しいリソースを作成する場合があります。POSTを使用して、他のいくつかの使用例を実装することもできますが、他の使用例（GET、PUT、DELETE、HEAD、OPTIONS）ではカバーされていません。
CRUDシステムの一般的な理解は、GET =要求、POST =作成、Put =更新、DELETE =削除です。
RESTのビルディングブロックは、主にリソース（およびURI）とハイパーメディアです。このコンテキストで、GETはリソースの表現を取得する方法です（これは確かSELECTにCRUD用語でCRにマップできます）。
ただし、CRUD操作とHTTP動詞の間の1対1のマッピングを必ずしも期待する必要はありません。主な違いPUTとは、POSTその冪等財産についてです。リソースの完全に新しい表現を送信することを一般に意味するPOSTため、部分更新にも一般的に使用されますPUT。
私はこれを読むことをお勧めします：
HTTP仕様はまた、有用基準です。
PUTメソッドは、囲まれたエンティティが指定されたRequest-URIの下に格納されることを要求します。
[...]
POST要求とPUT要求の基本的な違いは、Request-URIの異なる意味に反映されています。POSTリクエストのURIは、囲まれたエンティティを処理するリソースを識別します。そのリソースは、データを受け入れるプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる個別のエンティティの場合があります。対照的に、PUTリクエストのURIは、リクエストに含まれるエンティティを識別します。ユーザーエージェントは、意図するURIを認識しており、サーバーはリクエストを他のリソースに適用してはいけません。サーバーがリクエストを別のURIに適用したい場合は、
一般的に言えば、これは私が使用するパターンです：
Symfonyプロジェクトは、CRUDメソッドをアップ参加してHTTPメソッドを維持しようとすると、そのリストにそれらが次のように仲間：
彼らがそのページで言っているように、「実際には、多くの最近のブラウザはPUTおよびDELETEメソッドをサポートしていません」ことに注意する価値があります。
私が覚えていることから、Symfonyはフォームを生成するときにそれらをサポートしないブラウザーのPUTとDELETEを偽装し、ブラウザーがサポートしていない場合でも理論的に正しいHTTPメソッドの使用にできるだけ近づけようとしますそれ。