15

楽観的同時実行制御（RESTfulスタイルのアーキテクチャなど）でのetagの使用を理解しており、同じリソースの表現ごとにetagが異なる必要があることを読みました。何故ですか？

最終的には、リソースが変更されたかどうかを知り、同時変更を処理できるようにすることに関心がありませんか？リソース自体を変更せずにリソースの表現がいつ変更されるかを想像することすら困難であるため、基本的な理解が不足していることは明らかです。

4

2 に答える 2

10

良い質問です。これは議論の余地があると思います。

ほとんどの人は、ETag はリソース バージョンだけでなく、コンテンツ タイプも表していると言うでしょう。これは、コンテンツ タイプ、言語などに基づいて応答をキャッシュする場合に適しています。

次のリンクを確認してください。

于 2011-04-22T03:46:30.063 に答える
4

これは、事実を説明するとき、またはHTTP＆HTTPbis仕様を読むときに議論の問題ではありません。

ETagは、キャッシュと同時実行制御の手段です。弱いETagは、貧乏人のキャッシュの手段にすぎません。

キャッシング（GET）に関して-uri + content-type + etagは、ペイロードではなく、304ステータスコードで応答することにより、帯域幅を節約するのに役立ちます。

同時実行制御（POST; PUT; PATCH）の観点から、URI+コンテンツタイプ+ビット正確な応答ペイロードに基づいてETagを計算することは重要です。なんで？

  • オブジェクト全体、つまり応答ペイロードのスーパーセットに基づいてETagを計算する場合（つまり、ペイロードはa + bを返しますが、オブジェクトは実際にはa + b + cです）、たとえばPATCHを実行すると、失敗することになります。 ETagが変更されました...更新します..同じデータを取得しますが、異なるETagを取得します...新しいETagでPATCHを再試行すると、機能するようになります。不合格
  • ペイロードのサブセットに基づいてETagを計算する場合、実際には、透過性がまったくない状態で、ユーザーが安全でない呼び出しの条件を制御できないように強制します。そのETagに関連付けられたデータが変更された場合でも、PATCHは成功します。これは、明らかにHTTPリクエストが意図された方法ではありません。不合格

条件付きリクエストは、「私の世界観が同じであると仮定して、リクエストを実行します。それ以外の場合は失敗します」と同様のセマンティクスで処理する必要があります。私の世界観は、過去の応答（URI +ヘッダー+ペイロード）から作られています。

于 2013-01-10T16:44:38.880 に答える