「RESTfulWebServices」の作者であるSamRubyは、部分的な更新にHTTP PUTを使用することに反対しているようです：http：//intertwingly.net/blog/2008/02/15/Embrace-Extend-then-Innovate
明確ではないのは、部分的な更新をどのように行うべきかということです。彼のブログの下部近くでコメントしたように、HTTPPUTに対して「パッチドキュメント」を使用するよりもHTTPPATCHを使用する方が優れているかどうかは明らかではありません。
サムはHTTPPUTの誤用に反対していますが、HTTPPATCHの使用も支持していないようです。
RESTfulな部分更新をどのように送信する必要がありますか？
参照したブログ投稿のコメントからわかるように、部分的な更新を行うための合意された方法はありません。サム・ルビー、ジョー・グレガリオ、マーク・ノッティンガム、マーク・ピルグリム、ビル・デ・オーラなどの大物が合意に達することができない場合、私たちにはどんな希望がありますか.
私に関する限り、あまり心配することはありません。自分に合った部分更新メディア タイプを作成し、PATCH を使用して意図を示し、汎用メディア タイプで最終的に合意に達したら、サーバーを変更して両方のフォーマットを受け入れます。
REST API がコミットする最悪の罪が PUT/PATCH の悪用である場合は、かなりうまくやっていることに感謝してください。
現在は 2013 年です。部分的な更新には PATCH を使用する必要があります。json-patch を使用します ( https://www.rfc-editor.org/rfc/rfc6902またはhttp://www.mnot.net/blog/2012を参照/09/05/patch ) または xml-patch ドキュメント ( https://www.rfc-editor.org/rfc/rfc7351を参照)。ただし、私の意見では、json-patch がビジネス データの種類に最適です。
JSON/XML パッチ ドキュメントを使用した PATCH は、部分的な更新に対して非常に単純なセマンティクスを持っています。元のドキュメントの変更されたコピーを使用して POST を使用し始めると、部分的な更新のために、欠損値 (またはむしろ null 値) で「このプロパティを無視する」または「このプロパティを空の値」 - そしてそれはハッキングされたソリューションのうさぎの穴につながり、最終的には独自の種類のパッチ形式になります.
ここでより詳細な回答を見つけることができます: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html。
更新: これは RPC ですか?
RPC をサーバーにコマンドを送信するものとして定義すると、すべての HTTP 操作は RPC 呼び出しになります。リソースを GET するか、新しい表現を PUT するか、再度 DELETE するかに関係なく、それぞれがコマンド (動詞) GET の送信で構成されます。 /PUT/DELETE などとオプションのペイロード。HTTPワーキンググループ（またはそれが誰であるか）が、クライアントがリソースに対して部分的な更新を行うことを可能にする新しい動詞PATCHを導入しただけです。
完全な表現をサーバーに送信すること以外が RPC スタイルと見なされる場合、定義上、部分的な更新を RESTful にすることはできません。この観点を持つことを選択することはできますが、Web インフラストラクチャの背後にいる人々は別の言い方をしています。したがって、この目的のために新しい動詞を定義しました。
RPC は、Web 上の仲介者には見えない方法で HTTP を介してメソッド呼び出しをトンネリングすることに関するものです。たとえば、SOAP を使用してメソッド名とパラメーターをラップします。ペイロード内のメソッドとパラメーターを定義する標準がないため、これらの操作は「不可視」です。
これをメディア タイプ application/json-patch の PATCH と比較してください。動詞 PATCH には明確に定義された意味があり、ペイロードは別の明確に定義された公開されている形式でエンコードされているため、操作の意図は Web 上のすべての仲介者に明確に表示されます。 Web 上の共通機関 (IETF) によって。最終的な結果は、誰にとっても完全な可視性であり、アプリケーション固有の秘密のセマンティクスはありません。
REST はまた、"偶然の再利用" に関するものでもあります。これはまさに PATCH with application/json-patch と同じです - 多かれ少なかれ同じことを行うアプリケーション固有のプロトコルを発明する代わりに、既存の標準を再利用します。
部分更新メディア タイプを自作し、まだ非標準の PATCH メソッドを使用する代わりに、リソースの一部に独自の URI を与えることができます。
HTTPPATCHに RFCが追加されました-HTTPPATCHRFC