RESTful API設計とWebSocket統合

RESTはCRUDをHTTPにマッピングします。読み取りにはGET、作成にはPOST、部分更新にはPATCH、削除にはDELETEです。ステータスコードは正直に使いましょう――エラーのJSONを200で返すとクライアントが壊れます。

パスにバージョンを含め（/v1/）、大きなリストはページネーションし（追記専用のストリームにはカーソル形式のフィードを使う）、破壊的変更は非推奨期間を設けて文書化しましょう。

APIキーは身元を示し、シークレットは証明します。取引エンドポイントでは、シークレットが通信経路に乗らないよう、正規化された文字列（メソッド＋パス＋ボディ＋タイムスタンプ）をHMACで署名しましょう。リプレイをブロックするため、古すぎるタイムスタンプは拒否します――±30秒が一般的なウィンドウです。

OAuthはサードパーティアプリに向いています。純粋な取引所ボットは多くの場合、キー＋HMACのまま運用されます。レート制限：429を想定し、Retry-Afterヘッダーを尊重しましょう。

セッションはUpgrade: websocket付きのHTTP GETとして始まり、サーバーは101 Switching Protocolsを返します。その後、フレームはHTTPポーリングでのTLSハンドシェイクの繰り返しに比べて安価です。

サブスクライブメッセージは通常JSONです。メソッド、チャンネル、そしてプライベートな約定情報のための認証署名を含むこともあります。

取引のストリームはティックデータであり、オーダーブックはシーケンス番号付きのスナップショット＋デルタです。シーケンスを見逃した場合は、RESTのスナップショットから再同期し、シーケンス番号がスナップショットより大きいデルタを適用してください。

ハートビート：pingを送るか、サーバーからのpingを受け取ることを想定してください。サンダーヒングハード（一斉再接続）を避けるため、ジッターを加えたバックオフで再接続しましょう。

GraphQLはダッシュボードにおける過剰なフェッチを削ります。多くの取引所は、取引のホットパスにはそれでもRESTを公開しています。OpenAPI（Swagger）の仕様はコード生成とQAを助けます――例は必ずコピー＆ペースト可能な状態にしておきましょう。

WebSocketのループをタスクとして動かし、最新価格をスレッドセーフなマップに格納し、ヘルスチェック用にHTTPを公開しましょう。再接続の回数をログに記録し、それが急増したらアラートを出しましょう。