Web API The Good Parts読んだメモ2 〜キャッシュ周り〜

March 7, 2015

キャッシュ基本的なこと

キャッシュのメリット

  • サーバへの通信を減して、ユーザーの体感速度を上げられる
  • ネットワーク接続が切れた状態でもある程度使える
  • 通信コストを下げることができる
  • サーバの維持費用を抑えることができる

HTTPの2種類のキャッシュモデル

RFC2616に2種類のキャッシュの方法が記されている。

  • Expiration Model(期限切れモデル)
  • Validation Model(検証モデル)

Expiration Model(期限切れモデル)

期限切れモデルは、あらかじめレスポンスデータに保存期限を決めておき、期限が切れたら再度アクセスをして取得を行うというもの。

期限切れモデルに関するHTTPレスポンスヘッダー

キャッシュの有効期間を具体的は日付を指定する方法と、レスポンスを受け取ってからの秒数で指定する方法がある。

Header 指定方法 利用シーン
Expires 日付指定 いつ更新するか決まっている場合など
Cache-Control “max-age=” レスポンスを受け取ってからの秒数指定 頻繁に更新されるものとか

Validation Model(検証モデル)

検証モデルは今保持しているキャッシュが最新であるかを問い合わせて、データが更新されていた場合にのみ取得を行うというもの。 この問い合わせを条件付きリクエストという

  • 変更されている場合(この状態をstaleというらしい)はデータが帰ってくる
  • 変更されてない場合は304 not modified

条件付きリクエストのためのHTTPヘッダ

更新されているかの確認にはEtagを使う方法とLast-Modifiedを使う方法がある

  • Last-Modifiedヘッダ
    • Last-Modifiedは名前の通り最終更新時刻。
    • Last-Modified: Tue, 01 Jul 2014 00:00:00 GMT
  • Etagヘッダ
    • Etagはリソースの状態をあわらす識別子でリソースが更新されるとこの識別子も変わる。
    • ETag: "ff39b31e285573ee373af0d492aca581"

これらがレスポンスヘッダに書いてあるので、条件付きリクエストを投げる際に以下のヘッダにこれらを設定する

Header 設定値 利用シーン
If-Modified-Since Last-Modified 時間を使って条件付きリクエストする場合
If-None-Match Etag ETAGを使って条件付きリクエストする場合

多言語対応とキャッシュ

  • 同じURLでも、言語を切り替えた場合などキャッシュが使われると困る。
  • Varyヘッダーを使う

    この場合、同じURIでもAccept-Languageの値によって内容が同一ではなくなるため、URIだけを見てキャッシュをしてしまうと、本来取るべきデータを取ることができなくなってしまいます。たとえばクライアント側でユーザーが表示言語を切り替えた場合などに、キャッシュが表示されてしまうと設定が正しく変更されていないように見えてしまうはずです。 そこでVaryヘッダを使って、どのリクエストヘッダをキャッシュをするかどうかの判断に使うのかを指定します。

このエントリーをはてなブックマークに追加