データ選定
REST と WebSocket 相場 API の違いとアーキテクチャ設計
REST ポーリングと WebSocket プッシュ配信をリアルタイム性、リクエスト消費、実装コストの面から比較し、推奨のハイブリッド構成を解説します。
更新日時：
保守運営：AllTick 公式エンジニアリングチーム
対象読者：相場データ取得アーキテクチャを設計するバックエンド・データエンジニア
要約 · 30秒開発サマリー
REST は「1回リクエストして1回応答を受け取る」方式で、定期バッチ取得や過去ローソク足、低頻度クエリに適しています。WebSocket は常時接続を確立してサーバーから継続的にプッシュ受信する方式で、秒単位以下のリアルタイム相場に最適です。本番システムでは WebSocket でリアルタイム配信を受け、REST で過去データ補完と整合性チェックを行う併用構成が標準です。
01
主要特性の比較
| 比較項目 | REST API | WebSocket API |
|---|---|---|
| 通信モデル | リクエスト／レスポンス（ステートレス） | 常時接続・サーバープッシュ |
| リアルタイム性 | ポーリング間隔に依存 | イベント発生時に即時配信 |
| クォータ消費 | ポーリングごとにリクエスト数を消費 | 主に同時接続数と購読銘柄数で制限 |
| 実装の複雑さ | 低い（単発 HTTP 呼び出し） | ハートビート、再接続、再購読の実装が必要 |
| 主な用途 | 過去ローソク足、スナップショット、一括照会 | リアルタイム歩み値、リアルタイム板情報 |
02
プロトコル選定フロー
1更新頻度はどの程度か？分単位以上なら REST で十分。秒単位以下なら WebSocket を選択。
2同時に監視する銘柄数は？多数の銘柄を高頻度でポーリングすると REST クォータが即座に枯渇します。
3常時接続を保守できるか？WebSocket にはハートビート送信、指数バックオフ再接続、自動再購読が必要です。
4ヒストリカルデータが必要か？過去ローソク足の取得には REST を使用します。
03
推奨されるハイブリッド構成
- 起動時に REST で直近のローソク足を取得し、チャートやテクニカル指標の初期値とする。
- 続いて WebSocket を接続し、対象銘柄のリアルタイム歩み値や板情報を購読する。
- ネットワーク切断からの再接続後、切断中に欠損したローソク足を REST で補完する。
- 定期的に REST スナップショットでローカル状態を照合し、ズレがあれば補正する。
04
AllTick におけるエンドポイント対応
AllTick の株式 REST API は quote-stock-b-api プレフィックスを使用し、最新約定（/trade-tick）、板情報（/depth-tick）、ローソク足（/kline）を提供します。株式 WebSocket は quote-stock-b-ws-api です。為替・貴金属・コモディティは stock を含まない quote-b-api および quote-b-ws-api を使用します。
仕様出典と検証記録 · 2026-10-13
以下の一次資料で関連するエンドポイント、フィールド、取引所規則を確認しました。
今回の確認では実際の Token による AllTick 要求や本番エンドツーエンド試験は実行していません。再現時にプラン、ライブラリ版、取引時間、ret/trace、結果を記録してください。
一次資料
導入前に再現する項目
- 通信を切断し再接続・再購読後に REST と比較します。最新値だけでは全欠落約定を復元できません。
- Token 共有 worker の要求・接続数を集計します。株式と為替の URL は異なり、ping/pong はアプリケーション心拍の代替ではありません。