注文APIを評価する際に確認すべきこと
直接の回答
注文APIを評価する際は、APIが注文に対して実際に何を行うのか、結果をどのように確認できるのか、そして挙動があなたの期待とどこで異なり得るのかに焦点を当ててください。チェックリストは客観的に保ちましょう：安定した仕組み（リクエスト/レスポンス構造、ライフサイクルのセマンティクス）と、変動する条件（市場の動き、コスト、執行品質、ローカルルール）を分けます。結果は外部要因に依存するため、例は予測ではなく前提として扱ってください。
注文APIの仕組み（メカニズムと定義）
注文APIは、取引注文を送信・変更・取消しし、そのライフサイクルの状態に関する情報を取得するためのプログラム用インターフェースです。実務では通常、次のように扱います：
- 注文リクエスト：送信するデータ（例：注文タイプ、サイド、数量、time-in-force、必要な識別子）。
- 執行とアクノレッジ：受け取るレスポンス（受理、拒否、またはエラー）。
- 注文状態の更新：プロバイダーが時間の経過とともに報告する変化（オープン、部分約定、約定、取消し、期限切れ、拒否）。
- 照合（リコンシリエーション）識別子：意図をプロバイダーが報告した結果に突き合わせるための項目（例：クライアント注文IDやプロバイダー注文ID。対応している場合）。
重要な評価ステップは、ドキュメントをシステム用の明示的な状態モデルへ翻訳することです：どのステータスが存在するのか、どのように遷移するのか、そして注文、リトライ、更新に関してAPIが（何らかの）保証を提供しているのか。安定した仕組みとは、仕様書から推論できる部分です。変動する条件とは、リクエストと確認の間に変わり得るすべてのものです。
デューデリジェンスのチェックリスト（afvinkpunten）
以下の項目を使って、繰り返し可能な検証プロセスを構築してください。
1) 入力とセマンティクス（何を送るか）
- 必須項目と データ制約（許可される注文タイプ、最小/最大サイズ、有効なtime-in-force値）を確認します。
- APIが数量の単位や丸めルールをどう解釈するかを文書化します。「base」と「quote」の金額がどのように扱われるのか、数量、精度、そしてあなた自身の前提を明記してください。
2) 冪等性と重複保護（状態の不一致を防ぐ）
- APIが 冪等なリクエストをサポートしているか、またはタイムアウト後のリトライに関する文書化された戦略があるかを確認します。
- 同じリクエストが再送されたときに重複がどう扱われるかを検証します（同じクライアントIDか、新しいリクエストか）。自動化システムではリトライロジックが一般的なため、これは重要です。
3) 注文ライフサイクルと照合（証拠または文書）
- 注文ライフサイクルを完全に確認します：どのステータスが起こり得るのか、そして遷移がどのように報告されるのか。
- 照合に必要な項目（注文ID、タイムスタンプ、約定済み数量、残数量、拒否理由）を確認します。
- 「完了」の基準を定義します（例：filled/cancelled/rejected/expired のようなターミナル状態を受け取った時点で注文が閉じたとみなす—プロバイダーの文書化されたセマンティクスに基づく）。
4) 更新と配信モデル（何を観測できるか）
- ステータス情報がポーリング、ストリーミング/ウェブフック、または両方で提供されるかを判断します。
- 更新が非同期の場合、イベント順序とイベント完全性に関する保証を確認します。照合ロジックは、更新が欠落したり遅延したりすることを明示的なシナリオとして扱うべきです。
5) コストと執行の前提（何が変わり得るか）
- リクエストから最終ステータスまでの間に結果を変え得るコストと執行の影響を特定します：手数料、スプレッド、スリッページ、部分約定、そしてレイテンシー。
- 例を示す際は前提を明記します（例：「手数料はXで、約定は1回の執行で起こる」と仮定する）。そのうえで、実際の条件は乖離し得ることを注記してください。
6) 失敗パターン（rode vlaggen）
次の一般的な失敗パターンを探し、テストしてください：
- 拒否された注文（バリデーションエラー、十分でない権限、または無効なパラメータ）。
- タイムアウトと一時的なエラー（クライアントはリトライするかもしれないが、プロバイダーはすでにリクエストを処理済みの可能性がある）。
- 部分約定（注文が部分的に執行され、「残数量」に対応するロジックが必要になる）。
- 不一致の状態（あなたのシステムが、片方の状態ソースともう片方の状態ソースで異なるステータスを見てしまう）。
ドキュメントがこれらの挙動を明確に指定していない場合、それを危険信号として扱い、保守的な照合とモニタリングの計画を立ててください。
制約とリスク（何が起こり得るか）
注文の執行と注文状態の結果は、市場環境とプロバイダーの挙動に依存し、完全には制御できません。過去の関係は将来の結果を保証せず、慎重な仕様であってもストレス下（高ボラティリティ、ネットワークの問題、またはプロバイダー側のメンテナンス）では失敗し得ます。明示的に認めるべき重要な制約には次が含まれます：
- 意図と執行の不確実性：アクノレッジは、必ずしも最終的な執行を意味しません。
- 非アトミックな結果：部分約定と、その後の取消しによって、1つの指示に対して複数の状態が生じ得ます。
- 観測可能性のギャップ：遅延や更新の取りこぼしにより、システムが現在のステータスを誤って解釈する可能性があります。