REST APIのタイムゾーン — 設計パターンと標準
タイムゾーン対応REST APIの設計方法。リクエスト/レスポンスフォーマット規約、ヘッダーベースのタイムゾーンネゴシエーション、一般的なAPIタイムゾーンパターンを解説します。
Development
詳細な説明
REST APIでのタイムゾーン処理
タイムゾーンを正しく処理するAPIを設計するには、タイムスタンプの送受信方法に関する一貫した規約が必要です。
タイムスタンプフォーマット:常にISO 8601 + UTC
APIレスポンスはISO 8601フォーマットでZサフィックスまたは明示的オフセット付きを使用すべきです:
{
"createdAt": "2024-03-15T14:30:00Z"
}
リクエストでのユーザータイムゾーン
3つの一般的なパターン:
- クエリパラメータ:
GET /api/events?timezone=America/New_York - リクエストヘッダー:
X-Timezone: America/New_York - ユーザープロファイル設定:サーバーサイドで適用
UTCとローカル時間の両方を返す
ユーザー向けAPIでは、両方を返すと便利です:
{
"event": {
"startsAt": "2024-03-15T14:30:00Z",
"startsAtLocal": "2024-03-15T10:30:00-04:00",
"timezone": "America/New_York"
}
}
スケジューリングAPI
スケジューリングエンドポイントでは、ローカル時間とタイムゾーンIDの両方を受け入れます。これにより、サーバーはDST境界を含む各発生の正しいUTC時間を計算できます。
バリデーション
常にサーバーサイドでタイムゾーンIDを検証します:
function isValidTimezone(tz) {
try {
Intl.DateTimeFormat(undefined, { timeZone: tz });
return true;
} catch {
return false;
}
}
ユースケース
APIタイムゾーン規約は、日付と時刻を含むすべてのクライアント-サーバーインタラクションに影響します。ECプラットフォーム、SaaSアプリケーション、カレンダーAPI、分析ダッシュボード、予約システム、ソーシャルメディアプラットフォームはすべて、クライアントアプリケーションのバグを防ぐためにAPIコントラクトで一貫したタイムゾーン処理が必要です。