問題タブ [http-patch]

Patch 動詞の RFC 仕様を読むと、Patch動詞がエンティティを部分的に更新するための値を取得するのではなく、操作を行う必要があることが明らかです。

...ただし、PATCH を使用すると、囲まれたエンティティには、現在オリジン サーバーに存在するリソースを変更して新しいバージョンを生成する方法を説明する一連の指示が含まれます。

パッチの説明にあるように、デルタクラスのMSDNでも明らかです。

このデルタによって追跡される変更で元のエンティティを上書きします。

Putの説明とは異なり:

このデルタに格納されている値で元のエンティティを上書きします。

ここまではうまくいきましたが、これらの「指示」を OData で送信する方法を見つけることができませんでした。何をしても、Delta.Patch は値を置き換えるだけです。

パッチリクエストの構文は何ですか?

私が試した方法は次のとおりです。

と

そしてそれに近いもの。

アップデート：

Michael Moore に感謝し、ILSpy で Delta クラス全体を読んだ結果、これは実際に Patch 動詞設計のバグだと思います。
Microsoft のバグをオープンしました。修正が必要な場合は、投票してください。

REST API に一連のリソースがあります。次のように言いましょう。

「監視を停止」コマンドをパッチとして実装しました。

「すべてのフォルダの監視を停止する」を実装する正しい方法は何ですか? と思いました

しかし、これが理にかなっているのかどうかはわかりません (コレクション自体にはwatchedプロパティがありません)。

それとも、API レベルでまったく実装すべきではない (代わりにクライアントによって反復される) ものですか?
しかし、それは非効率に思えるでしょう。

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

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

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

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

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

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

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

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

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

翻訳のリストを提供する簡単なリソースがあります。get エンドポイントは言語を受け取り、翻訳の辞書を返します。更新は 1 つの翻訳のみに適用されるため、パッチとして行うのが適切であると考えました。

私の API コントローラーでは、put を正常に動作させることができますが、パッチ エンドポイントに対して行う呼び出しで 403 禁止エラーが発生し、その理由がわかりません。

一部のユーザーが他のユーザーの場所の変更を追跡し、場所が更新されるたびに websockets から通知を受けるレールサーバーを構築しています。

現在、場所を更新して WebsocketRais トリガーを呼び出すために、通常の更新を呼び出す代わりに update_location アクションを呼び出します。これは私には本当に奇妙に思えますし、もっと良い方法があるはずだと思います。

私が知っている唯一の他のオプションは、更新アクションを呼び出して、場所が更新されているかどうかを確認し、サブスクライバーに通知することです。これも私には非常に醜いようです。

リソースの Rails 更新を何らかの形でオーバーライドし、location 属性が更新されるたびにサブスクライバーに通知できるようにしたいと考えています。これは、設定以外のことを行う location 属性のセッター メソッドのようなものです。それは可能ですか？どうすればそれができるでしょうか？

Apache HTTPClient バージョン 4.3.5 を使用しています。HTTP PATCH リクエストを作成しようとしています。

受信した実際のリクエストを確認すると、本文が関連付けられていませんでした。同様のコードは、HTTP POST リクエストに対しても正常に機能します。

多くのフィールドを持つモデル 'MyModel' があり、PATCH メソッドを使用してフィールド 'status' を更新したいと考えています。クラスベースのビューを使用しています。PATCHを実装する方法はありますか?

短い:標準に準拠し、RESTful であり、PATCH 要求を使用してリソースのコレクションを単一のリソースだけでなく個別に更新できるようにすることは良い考えですか?

ロング:

リソースのコレクションに対するバッチのアトミック更新を有効にする方法を公開することを検討しています。例：

コンテキストは、商用ソリューションのパブリック API です。このような PATCH を許可する利点は、アトミック性と、リクエストのスパム送信や個別の失敗の処理などを伴わないバッチ処理のしやすさです。

https://www.rfc-editor.org/rfc/rfc6902およびhttps://www.rfc-editor.org/rfc/rfc5789に相談しましたが、これが準拠している場合、決定的な答えを見つけることができませんでした。RFC は主に「リソース」を参照していますが、リソースのコレクションもそのように扱うことができます。

これは良い考えですか？より良い代替手段はありますか？

リソースに対して非同期更新を行う必要があります。202 Accepted が PATCH に対する適切な応答であるかどうかについての決定的な声明はありますか?

公式ドキュメントhereでは、202 について言及されておらず、PATCH によるリソースの変更が同期的に行われると想定しているように見えますが、明確な声明を出すことはありません。

PATCH アクションの適切な回路図は何ですか?