完全にハイパーメディア駆動型の API があるとします。消費者は、必要なリソースにたどり着くまで、次のハイパーメディアを介して 3 つのリソースをナビゲートする必要があります。クライアントがこれらのステップを一時的にキャッシュして、必要なリソースに直接移動できない理由はありますか?
REST の目的がクライアントとサーバーを切り離すことであることは知っていますが、5 つの Web リクエストが舞台裏で進行している場合、これらすべてが発生するのを待っていると、ユーザー エクスペリエンスが低下する可能性があります。
考えられる最悪のケースは、キャッシュされた URL が変更されることです。そのため、クライアントは再びエントリポイントから開始し、ステップをキャッシュします。
クライアント側でのキャッシングは、パフォーマンスの高い Hypermedia クライアントの多くにとって非常に重要になります。以下は、フィールディングの論文からのより具体的なガイダンスです。
キャッシュ制約を追加する利点は、一部の対話を部分的または完全に排除し、一連の対話の平均待ち時間を短縮することで、効率、スケーラビリティ、およびユーザーが認識するパフォーマンスを向上させる可能性があることです。ただし、トレードオフとして、キャッシュ内の古いデータが、要求がサーバーに直接送信された場合に取得されたデータと大幅に異なる場合、キャッシュの信頼性が低下する可能性があります。
これにはトレードオフがありますが、イベントのキャッシングの時間枠が短いと、パフォーマンスが大幅に向上します。理想的には、Hypermedia API がキャッシング ガイダンスを提供します。これは、HTML キャッシングがブラウザーと Expires および Cache-Control ヘッダーで機能するのと同じ方法で行うことができます。
また、リソースが移動した場合、API は適切な 301 Moved Permanently 応答で通知する必要があります。