2010-12-12 3 views
2

他の開発者がWebキャッシングのコンテキストでhttp://www.w3.org/DesignIssues/Axioms.html#opaqueをどのように調整しているか不思議です。私は、URI-opaqueではないにもかかわらず、acceptsヘッダーに頼るのではなく、必要な書式、つまり.jsonまたは.xmlに基づいて、Railsの接尾辞付きリソースリクエストの方を好んでいます。URIの不透明度とキャッシングの公理

同じ問題は、XHRでその頭を元に戻します。標準HTTPリクエストと区別するためのクエリパラメータを追加しないと、キャッシュを無効にする必要があります。

私は、URI不透明度の純粋な解釈が実用的よりも学問的かもしれないと私は個人的に選択しました。意見ですか?

+1

URLの不透明度は学術的ではありません。第三者があなたのURLについてあまりにも多くの仮定をするのを防ぎます。もしそうなら、あなたは、あなたのURLがGoogle、Yahoo、さまざまなプロキシキャッシュ、さまざまなブラウザなどの慣習に準拠していることを確認するために、後ろに曲がる必要があります。 –

答えて

3

URIの形式は、クエリパラメータを持つ要求が既定でキャッシュできないことに加えて、キャッシュ可能性とは何の関係もありません。 GET要求のキャッシュ可能性に関するすべては、サーバーレスポンスのCache-Control、Expires、およびLast-Modified(ヒューリスティックキャッシング用)ヘッダーによって駆動され、リソースが動的であるか静的であるかとは関係ありません生成された(またはむしろ、あなたのブラウザは気にしないし、違いを伝えることはできません)。

URL不透明度は、サービスがハイパーメディア主導型でなければならないRESTの主な原則の1つを促進するためのものであり、実際にはクライアントはいくつかのよく知られているエントリポイントURLを "知って"そうでない場合は、リンクとフォーム(またはそのAPIに相当するもの)をナビゲートします。

+1

合意 - 私が見る問題は、すべてのケースでURIが同じであるため、異なる受け入れヘッダ(HTML、XML、JSON)に対応するURIをキャッシュ可能にします。 – aceofspades

+1

実際には、真実ではありません。サーバのレスポンスに「Vary:Accept」を設定して、複数のキャッシュ「バリエーション」という概念を作成することができます。これは、実際には、同じURIに対して複数のキャッシュエントリを持ち、適切なクライアントに(クライアントのAcceptヘッダーに基づいて)適切なものを提供することができます。 –