4

RFC 5789の内容は次のとおりです。

PATCH メソッドは、リクエスト エンティティに記述された一連の変更が、Request-URI によって識別されるリソースに適用されることを要求します。一連の変更は、メディア タイプによって識別される「パッチ ドキュメント」と呼ばれる形式で表されます。Request-URI が既存のリソースを指していない場合、サーバーは、パッチ ドキュメントの種類 (null リソースを論理的に変更できるかどうか) やアクセス許可などに応じて、新しいリソースを作成することができます。

PUT 要求と PATCH 要求の違いは、サーバーが囲まれたエンティティを処理して、Request-URI によって識別されるリソースを変更する方法に反映されます。PUT 要求では、同封されたエンティティは、オリジン サーバーに格納されているリソースの変更されたバージョンと見なされ、クライアントは格納されているバージョンを置き換えるように要求しています。ただし、PATCH を使用すると、囲まれたエンティティには、現在オリジン サーバーに存在するリソースを変更して新しいバージョンを生成する方法を説明する一連の指示が含まれます。

私が持っているとしましょう{ "login": "x", "enabled": true }、そして私はそれを無効にしたいと思います。

投稿によると、「お願いします。ばかのようにパッチを当てないでください。」、適切な PATCH リクエストは次のようになります

[{ "op": "replace", "path": "/enabled", "value": false }]

ただし、次のリクエストを見てみましょう。

{ "enabled": false }

また、「オリジンサーバーに現在存在するリソースを変更する方法を説明する一連の指示も含まれています」。唯一の違いは、JSON オブジェクトの代わりに JSON プロパティが使用されることです。

それほど強力ではないように見えますが、配列の変更は必要に応じて他の特別な構文 ( など{"a":{"add":[], "remove":[]}}) を持つことができ、サーバー ロジックはいずれにせよ、より強力なものを処理できない可能性があります。

RFC による不適切な PATCH 要求ですか? もしそうなら、なぜですか？
一方、{ "op": "disable" }正しい PATCH 要求でしょうか?

4

1 に答える 1

2

唯一の違いは、JSON オブジェクトの代わりに JSON プロパティが使用されることです。

実際にはそれよりも少し深いです。RFC 6902への参照は重要です。最初のリクエストにはContent-Typeofapplication/json-patch+jsonがありますが、2 番目のリクエストはapplication/json

重要なことは、この目的に役立つ「差分メディア タイプ」を使用することです。JSON-PATCH を使用する必要はありません (私はjson-merge-patchの大ファンです) が、必要なものだけを使用することはできません。2番目の部分で質問しているのは、基本的に「独自のメディアタイプを作成できますか」であり、答えは「はい」です。それを文書化してIANAに登録してください。

于 2014-09-09T23:41:17.713 に答える