上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
「午後6時まで営業しています」という表示が役に立つのは、それを読む訪問者が、どこの午後6時なのかを理解している場合だけです。お店とは異なるタイムゾーンにいる訪問者には、お店の時刻ではなく、訪問者自身の現地時刻で比較した結果を示す必要があります。
1回のIP検索でtimezoneフィールドが直接返されるため、別の呼び出しをしなくても必要な情報が得られます。
GET /v1/ip?ip=203.0.113.44{
"status": "ok",
"ip": "203.0.113.44",
"version": 4,
"found": true,
"country": "Japan",
"country_code": "JP",
"region": "Tokyo",
"city": "Tokyo",
"postcode": "100-0001",
"lat": 35.6762,
"lon": 139.6503,
"timezone": "Asia/Tokyo",
"asn": 2345,
"org": "Example Telecom"
}お店自身のタイムゾーンで保存している営業時間を、取得したばかりのタイムゾーン識別子を使って訪問者のタイムゾーンに変換し、訪問者の現在の現地時刻と比較して、「営業中」と「営業時間外」のどちらを表示するかを決めます。あわせて、どの現地時刻の時点での表示なのかも示します。
異なる都市に拠点を持つお店では、1つの営業時間がどこにでも当てはまると想定するのではなく、各拠点で掲載している営業時間を、その拠点について保存しているタイムゾーンで確認し、それぞれを訪問者のタイムゾーンと個別に比較してください。これが最も重要になるのは、訪問者が同じページで2つの拠点を比較している場合です。異なるタイムゾーンにある拠点や、夏時間の扱いが異なる拠点では、まったく同じ瞬間に一方が営業中、もう一方が営業時間外と表示されることがあるからです。
何も言わずに変換して訪問者が理解してくれることを期待するのではなく、たとえば「現在は営業時間外です。お客様の時間で午前9時に開店します(Asia/Tokyo)。」のように、両方の情報をはっきり表示してください。明示することで、一方では夏時間によって時差が変わり、もう一方では変わらないという境界をまたいで営業している場合の混乱を避けられます。
営業中か営業時間外かの比較を一度だけ計算して、その真偽値を訪問者のセッションの残りの間キャッシュしてはいけません。午後5時55分に行った比較は「営業中」と表示され、営業状態そのものを再計算せずにキャッシュしていると、午後6時5分になっても誤ったままになります。訪問者のタイムゾーン識別子はセッション中は本当に変わらないためキャッシュしてかまいませんが、営業中か営業時間外かの実際の比較は、表示のたびに毎回新しく計算してください。
一年中固定のオフセットを維持している地域がある一方で、隣接する地域では年に2回時刻が切り替わることがあります。つまり、2つのタイムゾーン間の時差は一年を通じて一定ではありません。比較のロジックが、タイムゾーン識別子をもとに日付ライブラリに変換を任せるのではなく、時間単位のオフセットをハードコードしていると、夏時間の切り替え前後の数週間にちょうどずれが生じます。
訪問者のタイムゾーン識別子はセッション中は変わらないため、キャッシュする価値があります。お店が現在営業中かどうかは一日のうちに変わるため、営業中か営業時間外かという状態そのものをキャッシュするのではなく、キャッシュしたタイムゾーンを使って表示時にその比較を再計算してください。
昨日行われた注文が顧客のタイムゾーンで実際に何時だったかを確認する場合など、現在ではなく特定の時点でのオフセットがどうだったか、あるいはどうなるかを知る必要がある場合、/v1/timezoneは、まさにそうした過去や未来の確認のために、unixタイムスタンプとしてのtimeパラメータを任意で受け付けます。
この機能は、新しい訪問者のセッションごとに1回のIP検索でまかなえます。訪問の間キャッシュされる1回のリクエストなので、アクセスの多いオンラインストアでも、すべてのキーに含まれる1日あたり2,500件の無料リクエストの範囲に十分収まります。
世界中のオーディエンスに向けて「営業中」を正しく表示するのは、複雑な機能ではなく、1回の検索とわかりやすい時刻の比較で済むことです。レスポンスの形式の全体はIPv4検索のドキュメントに掲載しています。