既存の answerを拡張するにPUTは、HTTP がこの方法でメソッドを定義するという理由だけで、リソース状態の完全な更新 (上書き) を実行することになっています。HTTP/1.1 に関する元の RFC 2616はこれについてあまり明示的ではありません。RFC 7231はセマンティックの説明を追加します。
4.3.4 置く
PUT メソッドは、ターゲット リソースの状態を作成するか、要求メッセージ ペイロードに含まれる表現によって定義された状態に置き換えることを要求します。特定の表現の PUT が成功すると、同じターゲット リソースに対する後続の GET によって、同等の表現が 200 (OK) 応答で送信されることが示唆されます。
他の回答で述べたように、この規則に従うことで API の理解と使用が簡素化され、PUT メソッドの動作を明示的に文書化する必要がなくなります。
ただし、冪等性のため、部分的な更新は許可されません。これらの概念は、多くの StackOverflow の回答でも混同されることが多いため、これを強調することが重要であると思います (例:ここ)。
べき等とは、リクエストを 1 回または複数回適用すると、サーバーに同じ効果が生じることのみを意味します。RFC 7231 をもう一度引用するには:
4.2.2 冪等メソッド
要求メソッドは、そのメソッドを使用した複数の同一の要求のサーバーに対する意図された効果が、単一のそのような要求の効果と同じである場合、「冪等」と見なされます。
部分的な更新にリソース状態の新しい値のみが含まれ、以前の値に依存しない (つまり、それらの値が上書きされる) 限り、冪等性の要件は満たされます。このような部分的な更新が適用される回数に関係なく、サーバーの状態は常に要求で指定された値を保持します。
別のクライアントからの中間要求がリソースの別の部分を変更できるかどうかは関係ありません。冪等性は状態自体ではなく操作(つまりメソッド) を参照するためです。PUTまた、部分上書き更新の運用については、1回でも複数回でも同じ効果が得られます。
逆に、べき等でない操作は、現在のサーバーの状態に依存するため、実行回数によって結果が異なります。これの最も簡単な例は、数値をインクリメントする (非冪等) 対絶対値に設定する (冪等) です。
冪等でない変更の場合、HTTP はメソッドPOSTおよび をPATCH予見しますPATCHが、既存のリソースに変更を加えるように明示的に設計されていますPOSTが、リクエスト URI、本文の内容、およびサーバーへの副作用の関係に関しては、はるかに自由に解釈できます。
これは実際にはどういう意味ですか？REST は、HTTP プロトコルを介して API を実装するためのパラダイムです。これは、多くの人が妥当と考えている規則であり、採用または理解される可能性が高いものです。それでも、何が RESTful で何がそうでないかについては論争がありますが、それらを脇に置いても、REST は HTTP API を構築するための唯一の正しいまたは意味のある方法ではありません。
HTTP プロトコル自体によって、実行できることと実行できないことが制限されており、その多くは実際に実際に影響を及ぼします。たとえば、冪等性を無視すると、クライアントによって実際に発行されたリクエストの数がキャッシュ サーバーによって変更され、その後、アプリケーションが期待するロジックが混乱する可能性があります。したがって、標準から逸脱した場合の影響を認識することが重要です。
厳密に REST に準拠しているため、部分的な更新に対して完全に満足のいく解決策はありません (この必要性だけでは REST に反するとさえ言う人もいます)。問題はPATCH、最初はこの目的のためだけに作成されたように見える がべき等ではないことです。したがって、べき等部分更新を使用PATCHすると、べき等性の利点(任意の回数の自動再試行、単純なロジック、クライアント、サーバー、およびネットワークでの最適化の可能性) が失われます。PUTそのため、動作が明確に文書化されていて、ユーザー (および中間ネットワーク ノード) が特定の動作に依存しているために壊れない限り、使用が本当に最悪のアイデアであるかどうかを自問することができます...?