17

RESTを使用してリソースの一部（ステータスインジケーターなど）のみを更新する方法について、かなり手を振っています。

オプションは次のようです。

  1. HTTPにPATCHまたはMODIFYコマンドがないことを訴えます。しかし、RESTのHTTP MODIFY動詞で受け入れられた答えは？なぜそれが見た目ほど良い考えではないのかを示すのに良い仕事をします。

  2. パラメータでPOSTを使用し、メソッドを識別します（たとえば、「action」という名前のパラメータ）。いくつかの提案は、自己定義のメソッド名でX-HTTP-Method-Overrideヘッダーを指定することです。これは、実行しようとしていることに基づいて実装内で切り替えるという醜いことにつながり、POSTを特にRESTfulに使用する方法ではないという批判を受け入れるように思われます。実際、このアプローチを取ることは、RPCタイプのインターフェースのように感じ始めます。

  3. PUTを使用して、更新する特定の属性を表すリソースのサブリソースを上書きします。実際、これは事実上、サブリソースの上書きであり、PUTの精神に沿っているように見えます。

この時点で、私は＃3が最も合理的なオプションであると考えています。

これはベストプラクティスですか、それともアンチパターンですか？他に選択肢はありますか？

4

6 に答える 6

7

ステータスの更新を表示するには、2つの方法があります。

  1. 物事に更新します。それはPUTです。オプション3

  2. 事物の履歴に追加のログエントリを追加します。この一連のログエントリのリスト項目が現在のステータスです。それはPOSTです。オプション2。

あなたがデータウェアハウジングまたは関数型プログラミングタイプである場合、ステータスの変更に不信感を抱く傾向があり、静的で不変なものに新しい歴史的事実を投稿したいと思います。これには、物事を物事の歴史から区別する必要があります。2つのテーブルにつながります。

それ以外の場合は、物事のステータスを変更するための「更新」を気にせず、PUTに満足しています。これは、物とその歴史を区別せず、すべてを1つのテーブルに保持します。

個人的には、可変オブジェクトとPUT（「エラー訂正」を除く）の信頼性がますます低くなっていることに気づいています。（それでも、古いものはそのままにして、新しいものは以前のバージョンを参照して追加できると思います。）

ステータスが変更された場合は、ステータスログまたは履歴があり、その履歴に新しいエントリを追加するためのPOSTが必要だと思います。これが適用されるオブジェクトの「現在の」ステータスを反映するための最適化があるかもしれませんが、それは舞台裏の最適化です。

于 2010-02-05T15:50:10.787 に答える
5

オプション3（いくつかの分離されたサブリソースにPUTする）が現時点での最善の策であり、メインリソース自体にPOSTを使用することは必ずしも「間違っている」とは限りません。それについてです。

3に固執し、より詳細なサブリソースを使用します。本当にPATCHのような動作が必要な場合は、POSTを使用します。個人的には、PATCHが実際に実行可能なオプションになったとしても、このアプローチを使用します。

于 2010-02-05T15:50:22.317 に答える
5

HTTPにはPATCHコマンドがあります。これはRFC2068のセクション19.6.1.1で定義されており、 draft-dusseault-http-patch-16で更新され、現在RFCとして公開されるのを待っています。

于 2010-02-05T16:13:01.613 に答える
1

利用できない場合は、POSTとPATCHのエミュレートを行ってもかまいません。


これを説明する前に、POSTを使用して一般的な更新を行うことに何の問題もないことを言及する価値があります（ここを参照）。特に：

POSTが問題になるのは、他の方法が理想的に適している状況で使用する場合のみです。たとえば、あるリソースの表現である必要がある情報の取得（GET）、表現の完全な置換（PUT）などです。

本当に、複雑なリソースに小さな更新を加えるためにPATCHを使用する必要がありますが、それは私たちが望むほど広く利用可能ではありません。POSTの一部として追加の属性を使用することにより、PATCHをエミュレートできます。

私たちのサービスは、SAP、Flex、Silverlight、Excelなどのサードパーティ製品に公開されている必要があります。つまり、最小公分母テクノロジーを使用する必要があります。しばらくの間、GETとだけでPUTを使用できませんでした。 POSTは、すべてのクライアントテクノロジでサポートされていました。

私が行ったアプローチは、POSTリクエストの一部として「_method=patch」を使用することです。利点は次のとおりです。

（a）サーバー側での処理は簡単です-基本的に、PATCHが利用可能であると偽っています

（b）サードパーティに対して、RESTに違反していないが、ブラウザの制限を回避していることを示します。また、Railsコミュニティが数年前にPUTを処理した方法とも一致しているため、多くの人が理解できるはずです。

（c）PATCHがより広く利用可能になったときに簡単に交換できます

（d）それは厄介な問題への実用的な反応です。

于 2010-02-05T17:49:06.193 に答える
1

PATCHは、パッチまたは差分形式に適しています。それまでは、まったく役に立ちません。

カスタムメソッドを使用したソリューション2については、リクエストまたはヘッダーのいずれであっても、いいえ、いいえ、いいえ、いいえ、それはひどいです:)

有効な2つの方法は、サブデータを変更してリソース全体をPUTするか、そのリソースにPOSTするか、サブリソースにPUTするかのいずれかです。

それはすべて、リソースの粒度とキャッシュに対する意図された結果に依存します。

于 2010-02-08T08:33:02.563 に答える
0

答えが少し遅れていますが、このようなシナリオではJSONパッチの使用を検討します。

そのコアでは、リソースの2つのコピー（元のコピーと変更されたリソース）が必要であり、それに対して差分を実行します。差分の結果は、違いを説明する一連のパッチ操作です。

この例：

[
  { "op": "replace", "path": "/baz", "value": "boo" },
  { "op": "add", "path": "/hello", "value": ["world"] },
  { "op": "remove", "path": "/foo" }
]

一般的にハードリフティングを行うことができる多くのクライアントライブラリがあります

于 2019-01-29T10:42:03.247 に答える