私は REST API を設計しており、最近、動的コンテンツのキャッシングを最大限に活用する方法について考えました (このトピックに関する応答の後)、HTTP (したがって REST) の原則を尊重します。
明らかに標準的な解決策は (少なくとも私の理解では) etags を使用することですが、これによってリクエストの数が減ることはなく、サイズだけが減ります。
URLにバージョンを埋め込むことを考えていました（実際のコンテンツに基づいてサーバーで作成されます-シリアル番号またはハッシュ）。スキームとユーザー シナリオ、およびそれがどのように役立つかを説明し、質問をします。
設定
GET /entity/{id}/
一時的なリダイレクト先/entity/{id}/{current_version}とキャッシュなしのヘッダーを返します。
GET /entity/{latest_version}/
OK 応答を返し、永久にキャッシュします。
GET /entity/{old_version}/
410 Gone を返します (実際には古いバージョンを保持したくありません)。
GET /エンティティ/?[クエリ]
結果エンティティの現在のバージョンへのリンクのリストを返す検索です。キャッシュなし。
使用シナリオとそれがどのように役立つと思うか
ユーザー アプリケーション (AJAX) は常に何らかのクエリで開始され、エンティティの説明を取得する必要があります。単一のクライアント結果セットの変更はあまり動的ではないことが予想されるため、上記のスキームを使用し、クライアントがクエリから毎回新しい結果を取得することをお勧めしますが、ほとんどのエンティティが前回の訪問以降に変更されていない場合、それらは既にブラウザにキャッシュされています。この仮説が正しければ、リクエスト数と合計サイズが大幅に減少します。
etag を使用すると、URI スキームがはるかに単純になりますが、サーバー側の実装はおそらくより複雑で重いものになります。
注意事項と質問
1/entity/{id}/リストのバージョンを返すコレクションであるべきだと
誰かが提案することは知っていますが、バージョンは実際には保存されておらず、有用でもなく、望まれているわけでもありません。それは最新のものの同義語です。ここでの私の質問は、一般原則以外に、誰かがそれに問題があると思うかどうかです。これは保護された API です。この場合、SEO は気にしません。クライアントに対して透過的です。実際には、API は多かれ少なかれハイパーリンクされるため、通常は /entity/{id}/ を実際に直接呼び出すことは想定されていませんが、結果が返すものは何でも使用します。たとえば、コンテキストフリーリンクに使用できます。
2 古いバージョンの 410 Gone に疑問があります。一方では、このバージョンはもう利用できないため、クライアントはいずれにせよアクセスすべきではありません。一方、クライアントが最終的にそれを要求した場合 (何らかの理由で)、/entity/{id}/ への永続的なリダイレクトを返すことが理にかなっている場合があります (現在のバージョンへの一時的なリダイレクトよりもおそらく良いでしょう)。
3 リダイレクトといえば。301 は永続的なリダイレクト用に固定されていますが、一時的なリダイレクトには 302 が最適ですか? 最も重要なのはブラウザのサポートです (これは AJAX になります)。
4 もちろん、主な問題は、キャッシングに etag の代わりに URL を使用することです (ブラウザーのキャッシュを期待しています)。誰かが高負荷 (サーバーの機能、咳) の下で実際の経験を持っている場合は、それを共有していただければ幸いです。
その他の注意事項
さらに調査した結果、バージョン管理されたリソースに問題があり、それはリンクされたリソースの更新の伝播です。次の 2 つのオプションがあります。
リソースの特定のバージョンをリンクします。これは、逆方向リンクを介してリンクされたリソースの更新を伝播する必要があるため、サーバー側のロジックが重くて扱いにくいことを意味します。
/latest/ バージョンをリンクします。これは、リソースとリンクされたリソースの具象バージョンの両方がローカルにキャッシュされている場合でも、クライアント (ブラウザー) は、リンクされたリソースの最新バージョンを「チェック」するために /latest/ にリクエストを送信する必要があることを意味します。もちろん、これは小さなリクエスト (リダイレクトのみ) であり、リソースが変更されていない場合、場所は既にキャッシュされています。問題の 1 つは、(特定のバージョンへのクエリ結果とは逆に) そのようなリンクからリソースが頻繁にプルされることです。もう 1 つの (さらに悪い) 問題は、実際には古いバージョンのリソースが別のリソースの最新バージョンにリンクしているということです。これはデータの不一致である可能性があります (つまり、誰かがドキュメントを編集し、リンクされた添付ファイルも変更しました。クライアントには古いバージョンのドキュメントと新しいドキュメントがあります)。添付ファイル用）。
どちらのオプションも不十分です。このライトでは、動的データのキャッシングは「リーフ」レベルのリソースに対してのみ可能です - 他のリソースにリンクせず、バストは直接の属性値を持つだけです。
最終的な注意事項
調査と議論の結果、バージョン管理されたリソースは、一般的なアーキテクチャとして最も優れたアイデアではありません。測定後、機会があれば、「プレーンな」リソースの標準 API に何かを組み込むことができます。Roysvorkのコメント（「これが難しいのは、それが本当に良い考えではないというのが私の意見です」）を解決策として受け入れます。それが別の答えである場合:)