REST APIでHTTP PUTが部分的な更新を実行できないのはなぜですか？
RESTful APIはHTTP PATCHを介して部分更新を個別にサポートする必要があると言うのは誰ですか？
利点はないようです。どの種類の更新を要求するかを決定するために、サーバー側に実装する作業とクライアント側にロジックを追加します。
この質問は、既知のデータモデルに抽象化を提供するHTTPを使用したREST APIを作成するコンテキスト内で行っています。PUTではなく、部分的更新にはPATCHが必要です。利益が、私は説得することができます。
関連
http://restcookbook.com/HTTP%20Methods/idempotency/ -これは、要求をキャッシュする可能性のあるサーバーソフトウェアを制御できないことを意味します。
部分的なPUTを許可しない理由は何ですか？ -明確な答えはありません。HTTPがPUtとPATCHに対して定義するものへの参照のみです。
http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/17415 -これに関する考えの分かれ目を示しています。
誰が言う？ RESTを発明した人はこう言います：
@mnot Oy、はい、PATCHは最初のHTTP/1.1プロポーザル用に作成したもので、部分的なPUTは決してRESTfulではありません。 ;-)
https://Twitter.com/fielding/status/275471320685367296
まず、RESTはアーキテクチャスタイルであり、その原則の1つは、その基盤となるプロトコルの標準化された動作を活用することです。したがって、HTTP経由でRESTful APIを実装する場合は、厳密にRESTfulであるためのHTTP。あなたがあなたのニーズに十分でないと思うなら、そうしないことは自由です、誰もあなたのためにあなたを呪いませんが、それからあなたはRESTをしていません。どこからどのように標準から逸脱するかを文書化する必要があります。クライアントとサーバーの実装間に強力な結合を作成します。RESTを使用することは、それを正確に回避し、メディアタイプに集中することです。
したがって、RFC 7231に基づいて、PUTは、べき等の操作で表現の完全な置換にのみ使用する必要があります。 PATCHは、updates等である必要のない部分的な更新に使用する必要がありますが、diffを適用する前に前提条件を要求するか、現在の状態を検証することにより、dem等にすることができます。部分的であるかどうかに関係なく、べき等でない更新を行う必要がある場合は、POSTを使用します。シンプル。 PUTとPATCHの動作を知っているAPIを使用するすべての人は、それらがそのように動作することを期待しており、特定のリソースに対してメソッドが行うべきことを文書化または説明する必要はありません。 PUTを他の適切な方法で動作させることは自由ですが、それをクライアント向けに文書化する必要があります。また、RESTfulではないため、APIの別の流行語を見つける必要があります。
RESTは、APIの長期的な進化に焦点を合わせたアーキテクチャスタイルであることに注意してください。正しく行うにはwill今すぐに作業を追加しますが、後で変更を簡単にし、トラウマを少なくします。だからと言って、RESTがすべての人に適しているわけではありません。実装の容易さと短期間の使用に焦点を合わせている場合は、必要な方法を使用してください。クライアントが適切な方法を選択することに煩わされたくない場合は、POSTを介してすべてを実行できます。
既存の回答 を拡張するには、HTTPがこの方法でメソッドを定義しているという理由だけで、PUTはリソース状態の完全な更新（上書き）を実行することになっています。 HTTP/1.1についての元のRFC 2616 はこれについてあまり明確ではありませんが、 RFC 7231 は意味の説明を追加します：
PUTメソッドは、ターゲットリソースの状態を作成するか、要求メッセージペイロードに含まれる表現で定義された状態に置き換えることを要求します。特定の表現のPUTが成功すると、その同じターゲットリソースに対する後続のGETにより、200（OK）応答で同等の表現が送信されることが示唆されます。
他の回答で述べたように、この規則を順守すると、APIの理解と使用が簡単になり、PUTメソッドの動作を明示的に文書化する必要がなくなります。
しかし、部分的な更新はべき等性のために禁止されていません。これらの概念は、多くのStackOverflowの回答（例えば、 ここ ）。
べき等は、リクエストを1回または複数回適用すると、サーバーに同じ効果が生じることを意味します。 RFC 7231をもう一度引用するには：
要求メソッドは、そのメソッドを使用した複数の同一要求のサーバーに対する意図した効果が、そのような単一の要求の効果と同じである場合、「べき等」と見なされます。
部分的な更新にリソース状態の新しい値のみが含まれ、以前の値に依存しない（つまり、それらの値が上書きされる）限り、dem等性の要件は満たされます。そのような部分的な更新が何回適用されるかに関係なく、サーバーの状態は常にリクエストで指定された値を保持します。
別のクライアントからの中間リクエストがリソースの別の部分を変更できるかどうかは関係ありません。i等性はoperation（つまりPUTメソッド）を参照するため、状態自体。また、部分的な上書き更新の操作に関しては、そのアプリケーションは1回または複数回適用された後、同じ効果をもたらします。
それどころか、i等ではない操作は、現在のサーバーの状態に依存するため、実行回数に応じて異なる結果になります。これの最も簡単な例は、数値をインクリメントする（非べき等）対それを絶対値に設定する（べき等）です。
べき等でない変更の場合、HTTPはPOSTおよびPATCHメソッドを予測しますが、PATCHは既存のリソースへの変更を明示的に設計するのに対し、POSTはできるリクエストURI、本文コンテンツ、およびサーバー上の副作用の関係に関して、より自由に解釈されます。
これは実際にはどういう意味ですか？RESTは、HTTPプロトコルを介してAPIを実装するためのパラダイムです。多くの人が合理的であると考えているため、採用または理解される可能性があります。それでも、RESTfulで何がそうでないかについては論争がありますが、それらを残してさえ、REST HTTP APIを構築するための正しいまたは意味のある方法。
HTTPプロトコル自体は、ユーザーが実行できることと実行できないことに制約を課し、それらの多くは実際の実用的な影響を及ぼします。たとえば、べき等性を無視すると、キャッシュサーバーがクライアントによって実際に発行されたリクエストの数を変更し、その後アプリケーションが期待するロジックを混乱させる可能性があります。したがって、標準から逸脱する場合は、その影響を認識することが重要です。
厳密にRESTに準拠しているため、部分的な更新に対して完全に満足できるソリューションはありません（このニーズだけがRESTに反すると言う人もいます）。問題は、この目的のために最初に作成されたように見えるPATCHがべき等でないことです。したがって、i等部分更新にPATCHを使用すると、i等性（任意の数の自動再試行、より単純なロジック、潜在的なクライアント、サーバー、およびネットワークの最適化用）。そのため、ユーザー（および中間ネットワークノード）が特定の動作に依存しているため、動作が明確に文書化されており、破損しない限り、PUTの使用が本当に最悪のアイデアかどうかを自問することができます。