部分的な更新（パッチ）をRESTでサポートする方法

90

RFC5789（http://tools.ietf.org/html/rfc5789）によると、これはです正確に何PATCHです：ハイパーテキスト転送プロトコルを拡張

いくつかのアプリケーション（ HTTP）には、部分的なリソース変更を行う機能が必要です。既存の HTTP PUTメソッドでは、ドキュメントを完全に置き換えることしかできません。この提案では、新しいHTTPメソッドPATCHを追加して、既存の HTTPリソースを変更します。

PATCHとPUTとの間の区別は以下のように記述されるPUTとPATCH要求との間の差は、サーバにより識別されたリソースを変更するために同封エンティティを処理ように反映される

リクエストURI。 PUT要求では、同封されたエンティティは、オリジンサーバに保存されているリソースの修正バージョンと見なされ、クライアントは格納されたバージョンを置き換えるように要求しています。しかし、PATCHでは、同封されたエンティティは、オリジンサーバに現在存在するリソースが新しいバージョンを生成するためにどのように修正されるべきかを記述する指示のセットを含む。POSTの

の制限についても説明します：

PUTメソッドは、既に完全な新しいボディとリソースを上書きするように定義されており、部分的な変更を行うために再利用することはできません。それ以外の場合、プロキシとキャッシュ、さらにはクライアントとサーバーでも、操作の結果に関してが混乱することがあります。 POSTは、私はあなたがRFCを読んで、自分の心を作ることをお勧め

[...]（1のために、に標準的な方法がないパッチ形式のサポートを発見）広範な相互運用性なしですでに使用されているが、しかし私にとってこれはかなり明確なようです - PATCH要求は部分的な更新として処理されるべきです。（NBは、彼らがPUTとは異なり、冪等されません。）

EDIT：PATCH要求は"neither safe nor idempotent as defined by [RFC2616]"ですが、コメントでユージンで指摘したように、彼らはとても行うことができます。

PATCH要求を発行することができます等価であるような方法で、も同様の時間枠で同じリソース上の2つの PATCH要求の間の衝突による悪影響を防ぐのに役立ちます。複数のPATCH要求からの衝突は、 PUT衝突より危険です。一部のパッチ形式は、既知の基準点から動作する必要があるため、衝突する可能性があります。そうしないと、リソースが破損します。クライアントは、クライアントがリソースに最後にアクセスしてからが更新された場合に要求が失敗するように、この種のパッチアプリケーションを使用して条件付き要求を使用すべきです（SHOULD）。たとえば、クライアントは、Patch 要求のIf-Matchヘッダーで強力なETag [RFC2616]を使用できます。

出典

2012-02-29 09:23:42

+20

+1 '' If-Match 'を含めることによって '' PATCH''が** idempotent **になることを追加するかもしれません'ヘッダを参照してください。実際にRFCには、誤ったバージョンにパッチを適用すると参照全体が壊れる可能性があることが強く示唆されています。 –

+0

True - これをすべて有効にするには、ETagsを正しく生成/使用する必要があります。 –

+0

とにかく、キャッシングのための良いアイデアですが、特に部分的な更新を行う場合には、特定のバージョンのリソースにパッチを当てることが最も頻繁に必要な場合があります。時には十分なコンテキスト情報をdiffに埋め込むこともできますが、ETagsはdiff形式独自の方法であり、特定のdiff形式について何も知らない汎用フレームワークに簡単に統合できることがよくあります。 –

-17

PATCHは、ドキュメントレベルのパッチ適用のみ（実際の表現では別名として）のパッチフォーマットで使用します。他の目的に使用することは疑わしいものであり、議論の余地があります。この方法はメディア以外の用途に設計されていることは明らかではありません。

通常、POSTは適切なアプローチですが、代わりにリソースを複数のリソースに分割して変更することができます。

[いくつかのコメントを読んでいないとして、明確にするため編集]

出典

2012-01-24 15:48:47 SerialSeb

+6

を得ましたhow * prashanth *の要件を参照してください。 '私のリソースの部分的な更新は' PATCHがするはずのものと衝突するでしょう： 'エンティティは、新しいバージョンを生成するためにオリジンサーバに現在存在するリソースをどのように修正すべきかを記述するこれは** rfc5789 **のものですが、古い** rfc2068 **は似ています。また、 'diff on the actual bytes'に関しては、実装者がバイト範囲を実装するために必要なHTTP範囲と混同されることはありません（しかし、これは他のユニットにも拡張できます）。 –

+1

http範囲リクエストとパッチドキュメントを混同しないでください。いいえ、読者に混乱を招く可能性があることを指摘してくれてありがとう。問題の仕様は、パッチ文書がリソースの状態を変更する文書であり、そのような文書をどのように適用するかがあまり明確でなく、選択肢を残していることは明らかです。スペックの観点からは、条件付きで行うことが推奨されており、具体的な表現であることがわかっている例では強いetagが与えられています。既知のまたは公開されているdiff形式（ReSTで使用する）は文書固有のものなので、私の答えです。 – SerialSeb

+3

通常、リソースを更新するのではなく、リソースの作成にPOST要求が使用されます。 – ChrisV

0

RFC-7386「json merge PATCH」の説明のように、PATCHメソッドを使用する必要があります。

など。あなたのようなリソースに「」と「F」を取り除くの値を変更する場合：

{ 
    "a": "b", 
    "c": { 
     "d": "e", 
     "f": "g" 
    } 
    }

あなたは送信することで、これをachiveことができます。

 PATCH /target HTTP/1.1 
     Host: example.org 
     Content-Type: application/merge-patch+json 

     { 
     "a":"z", 
     "c": { 
      "f": null 
     } 
     }

出典

2017-11-09 09:03:54 TechnoPriest

部分的な更新（パッチ）をRESTでサポートする方法

答えて

関連する問題