【入門編】 RESTの4つの原則：キャッシュ可能性 – Web APIアーキテクチャ・データ連携実践ガイド

RESTの「キャッシュ可能性」って何？郵便配達で学ぶ、ネットワークの賢い節約術

こんにちは！ネットワークの世界にどっぷり浸かって十数年。今日も今日とてパケットの海を漂っているインフラアーキテクトです。

今回は、REST APIの設計において非常に重要な、でも意外と見過ごされがちな「キャッシュ可能性（Cacheability）」についてお話しします。

「キャッシュ」という言葉は、スマホの設定やブラウザの掃除で見かけるかもしれませんね。でも、APIの世界におけるキャッシュは、ただの「お掃除対象」ではなく、ネットワーク全体の健康を守るための最強の武器なんです。

小難しい専門用語は一旦置いておいて、まずは身近な例から紐解いていきましょう！

—

郵便配達でイメージする「キャッシュ」の仕組み

想像してみてください。あなたは、毎日決まった時間に、遠く離れた友人に「最新の天気予報」を教えてもらう手紙を送っています。

1. キャッシュなしの世界： 毎日毎日、あなたは郵便局へ行き、友人に手紙を出し、返事を待つ。天気予報なんて、せいぜい1日に数回しか変わらないのに、毎日郵便屋さんは往復の労力を使っていますよね。これでは、お互いに疲れてしまいますし、切手代（ネットワーク帯域）もバカになりません。
2. キャッシュありの世界： 友人が手紙にこう書いてくれました。「この予報は、今日の夕方5時までは有効だよ！」
これを聞いたあなたは、5時までは友人にわざわざ手紙を送る必要がありません。手元のメモ（キャッシュ）を見れば十分です。

REST APIにおける「キャッシュ可能性」とは、まさにこれ。「このデータはいつまで使っても大丈夫ですよ」というお墨付きをサーバーが与えることなんです。

—

なぜ「キャッシュ」がそんなに大事なの？

インフラの現場でよく聞く悲鳴の一つに、「APIのレスポンスが遅い！」「サーバーが過負荷でダウンした！」というものがあります。

キャッシュを活用すると、以下のメリットが生まれます。

応答速度の向上： サーバーまで問い合わせに行く必要がないので、手元で完結する分、爆速です。
帯域とコストの節約： ネットワークを流れるデータ量が減れば、それだけ通信費も抑えられ、回線の混雑も防げます。
サーバーの延命： サーバーは「また同じこと聞いてるな…」と対応しなくて済むので、本当に必要な新しいリクエストだけに集中できます。

—

「キャッシュできるよ！」と伝える魔法の言葉：HTTPヘッダー

Webの世界では、サーバーがブラウザやクライアントに対して、「このデータはキャッシュしていいよ」と伝えるために、特別なラベルを貼ります。これが Cache-Control というヘッダーです。

いくつか代表的な書き方を見てみましょう。

1. 「60秒間だけ使い回していいよ」

一番よく使われる設定です。

# 60秒間は、同じリクエストが来てもサーバーに聞かなくてOK！
Cache-Control: max-age=60

2. 「ずっと使い回していいよ（または二度とキャッシュしないでね）」

頻繁に変わるデータには、キャッシュさせない設定も重要です。

# 常に最新を取りに行ってね（キャッシュ禁止）
Cache-Control: no-store

—

実践！Web APIでの実装例

では、実際にWebフレームワーク（今回はPythonのFlaskを想定します）で、どのようにこの「魔法のラベル」を付けるのか見てみましょう。

from flask import Flask, make_response

app = Flask(__name__)

@app.route('/api/weather')
def get_weather():
    # 本来ならここでDBや外部APIから天気情報を取得します
    data = {"city": "Tokyo", "weather": "Sunny"}
    
    response = make_response(data)
    
    # ここがポイント！
    # 300秒間（5分間）はキャッシュしていいよ、とブラウザに伝えます
    response.headers['Cache-Control'] = 'public, max-age=300'
    
    return response

たったこれだけの記述で、クライアント（ブラウザやアプリ）は「よし、5分間はサーバーを休ませてあげよう」と判断してくれます。インフラエンジニアとしては、こういった「行儀の良い」API設計がされていると、非常に安心するんですよね。

—

まとめ：一歩ずつ、「賢い通信」を目指そう

RESTのキャッシュ可能性とは、単なる技術的な制約ではなく、「相手（ネットワークやサーバー）を思いやる心」だと私は考えています。

1. 変化の少ないデータには、有効期限を付ける。
2. キャッシュしてはいけない機密情報には、no-storeを付ける。

まずはこの2つから意識するだけで、あなたの作るAPIは一段と洗練された、プロ仕様の設計に近づきます。

ネットワークの世界は奥が深いですが、こうやって一つずつ噛み砕いていけば怖くありません。次回の記事では、キャッシュの更新タイミングをより細かく制御する「条件付きリクエスト」についてお話しします。

それでは、また次回の深淵でお会いしましょう！Happy Hacking!