開発者API
チェス レーティング API ドキュメント
Chess Rating API は、このサイトの計算機を動作させるのと同じ Elo 計算エンジンへのプログラムによるアクセスを提供します。クラブ管理ツール、トーナメントレポートダッシュボード、コーチングプラットフォーム、またはエディトリアル製品を構築している開発者は、数式ロジックを再実装することなく、レーティング計算をワークフローに直接統合できます。このドキュメントでは、利用可能なエンドポイント、リクエストとレスポンスの形式、認証要件、統合の安定性を維持するためのバージョン管理アプローチについて説明します。 関連する説明として、埋め込み可能なチェス評価ウィジェットも参考になります。
利用可能な計算エンドポイント
API は、単一ゲームのレーティング変更 (2 つのレーティング、結果、および K ファクターを指定)、バッチ処理 (1 回のリクエストで複数のゲーム記録)、および初期レーティング推定 (指定された平均対戦相手レーティング、スコア、ゲーム数) の 3 つの主要な計算ワークフローをサポートします。各エンドポイントは、予想スコア、評価デルタ、予測される新しい評価など、計算機ページに表示されるのと同じ詳細な出力を返します。 実装と検証の詳細は、検証方法をご覧ください。
トーナメント モードのエンドポイントは、順序付けされた対戦相手の評価と結果の配列を受け取り、ラウンドごとの内訳と累計を返します。すべての応答には、どのルール プロファイルが適用されたかに関するメタデータが含まれるため、下流の消費者は計算の前提を検証できます。
認証とレート制限
API アクセスには、Authorization ヘッダーでベアラー トークンとして渡される API キーが必要です。キーは無料レベルとプレミアムレベルで利用できます。無料利用枠では、1 日あたり最大 100 件のリクエストが許可され、バッチ リクエストごとに最大 10 ゲームが許可されます。プレミアム キーにより、より高いスループット、優先サポート、および一括トーナメント処理エンドポイントへのアクセスが可能になります。
レート制限は、IP アドレスごとではなく、キーごとに適用されます。制限を超えると、次の要求ウィンドウがいつ開くかを示す Retry-After ヘッダーを含む 429 ステータスが返されます。すべての制限は、成功したすべてのリクエストの応答ヘッダーに文書化されます。
ルールのプロファイルとバージョン管理
すべての API 応答には、計算にどの仮定セットが使用されたかを示す rules_profile フィールドが含まれます (例: fide_2024、us_chess_current、generic_elo)。フェデレーション規制が変更されると、API は既存のプロファイルを変更するのではなく、新しいプロファイル バージョンを追加します。これは、ダウンストリーム システムが特定のプロファイル バージョンに固定され、独自のスケジュールでアップグレードできることを意味します。
重大な変更は、API 変更ログと開発者メーリング リストを通じて、少なくとも 30 日前に通知されます。互換性のない追加 (新しいオプション フィールド、新しいプロファイル) は、既存の統合を中断することなく継続的にデプロイされます。
応答フォーマットとエラー処理
- すべての応答は、Content-Type: application/json の JSON を返します。計算が成功すると、完全な結果ペイロードとともに 200 が返されます。
- 検証エラー (フィールドの欠落、範囲外の評価、無効な K ファクター) は、人間が判読できるエラー配列とともに 422 を返します。
- 認証が失敗すると 401 が返されます。期限切れまたは取り消されたキーは、再アクティブ化 URL とともに 403 を返します。
- サーバー エラーは、サポート エスカレーションのリクエスト ID とともに 500 を返します。すべてのエラー応答は同じ { error, message, request_id } 構造に従います。
統合のベストプラクティス
API 呼び出しを最小限に抑えるために、可能な限り繰り返し計算をローカルにキャッシュします。トーナメント ワークフローの場合は、単一ゲームの連続リクエストを行うのではなく、バッチ エンドポイントを使用します。サーバーのデフォルトに依存するのではなく、必ず rules_profile パラメーターを明示的に含めてください。そのため、API が新しいプロファイルを追加した場合でも、統合は決定的なままになります。
クラブ ソフトウェアおよびコーチング ダッシュボードの場合は、フェデレーション ルールが変更された場合に後で監査または再計算できるように、計算結果と rules_profile バージョンの両方を保存することを検討してください。これは、履歴の正確性が重要となる公式レポートのワークフローでは特に重要です。