انتقل إلى المحتوى
حاسبة تصنيف إيلو للشطرنج

واجهة برمجة تطبيقات المطور

وثائق API لتقييم الشطرنج

توفر واجهة برمجة تطبيقات تقييم الشطرنج وصولاً برمجيًا إلى نفس محرك حساب Elo الذي يقوم بتشغيل الآلات الحاسبة على هذا الموقع. يمكن للمطورين الذين ينشئون أدوات إدارة النادي، أو لوحات معلومات تقارير البطولة، أو منصات التدريب، أو المنتجات التحريرية دمج حسابات التصنيف مباشرة في سير العمل الخاص بهم دون إعادة تنفيذ منطق الصيغة. تغطي هذه الوثائق نقاط النهاية المتاحة وتنسيقات الطلب والاستجابة ومتطلبات المصادقة ونهج الإصدار الذي يحافظ على استقرار عمليات التكامل. يمكنك المتابعة مع أدوات تقييم الشطرنج القابلة للتضمين للحصول على شرح مرتبط.

نقاط نهاية الحساب المتاحة

تدعم واجهة برمجة التطبيقات (API) ثلاثة مسارات عمل حسابية أساسية: تغيير تصنيف اللعبة الواحدة (بالنظر إلى تقييمين، ونتيجة، وعامل K)، ومعالجة الدفعات (سجلات ألعاب متعددة في طلب واحد)، وتقدير التصنيف الأولي (بالنظر إلى متوسط تقييم الخصم، والنتيجة، وعدد الألعاب). تقوم كل نقطة نهاية بإرجاع نفس المخرجات التفصيلية الموضحة على صفحات الآلة الحاسبة، بما في ذلك النتيجة المتوقعة ودلتا التصنيف والتقييم الجديد المتوقع. لتفاصيل التنفيذ والتحقق، راجع المنهجية.

تقبل نقاط النهاية في وضع البطولة مجموعة مرتبة من تقييمات الخصم ونتائجه، وإرجاع التقسيمات لكل جولة والإجماليات التراكمية. تشتمل جميع الاستجابات على بيانات تعريف حول ملف تعريف القواعد الذي تم تطبيقه حتى يتمكن المستهلكون النهائيون من التحقق من افتراضات الحساب.

المصادقة وحدود المعدل

يتطلب الوصول إلى واجهة برمجة التطبيقات (API) تمرير مفتاح API كرمز مميز لحامل في رأس التفويض. المفاتيح متوفرة في المستويات المجانية والمميزة. تسمح الطبقة المجانية بما يصل إلى 100 طلب يوميًا بحد أقصى 10 ألعاب لكل طلب دفعة. تفتح المفاتيح المميزة إنتاجية أعلى ودعمًا ذا أولوية وإمكانية الوصول إلى نقاط نهاية معالجة الدورات المجمعة.

يتم فرض حدود المعدل لكل مفتاح، وليس لكل عنوان IP. يؤدي تجاوز الحد إلى إرجاع الحالة 429 مع رأس إعادة المحاولة بعد الإشارة إلى وقت فتح نافذة الطلب التالية. يتم توثيق جميع الحدود في رؤوس الاستجابة لكل طلب ناجح.

ملفات تعريف القواعد والإصدارات

تشتمل كل استجابة لواجهة برمجة التطبيقات (API) على حقل ملف تعريف القواعد الذي يشير إلى مجموعة الافتراضات التي تم استخدامها للحساب (على سبيل المثال، fide_2024، us_chess_current، generic_elo). عندما تتغير لوائح الاتحاد، تضيف واجهة برمجة التطبيقات (API) إصدارًا جديدًا للملف الشخصي بدلاً من تعديل الإصدارات الحالية. وهذا يعني أن الأنظمة النهائية يمكنها التثبيت على إصدار ملف تعريف محدد وترقيته وفقًا لجدولها الزمني الخاص.

يتم إرسال التغييرات العاجلة قبل 30 يومًا على الأقل من خلال سجل تغييرات واجهة برمجة التطبيقات والقائمة البريدية للمطورين. يتم نشر الإضافات غير المنفصلة (الحقول الاختيارية الجديدة وملفات التعريف الجديدة) بشكل مستمر دون تعطيل عمليات التكامل الحالية.

تنسيق الاستجابة ومعالجة الأخطاء

  • تُرجع جميع الاستجابات JSON مع نوع المحتوى: application/json. تُرجع الحسابات الناجحة 200 مع حمولة النتيجة الكاملة.
  • تؤدي أخطاء التحقق من الصحة (الحقول المفقودة، والتقييمات خارج النطاق، وعامل K غير الصالح) إلى إرجاع 422 مع مصفوفة أخطاء يمكن قراءتها بواسطة الإنسان.
  • تؤدي حالات فشل المصادقة إلى إرجاع 401. وترجع المفاتيح منتهية الصلاحية أو الملغاة 403 بعنوان URL لإعادة التنشيط.
  • تُرجع أخطاء الخادم 500 بمعرف طلب لتصعيد الدعم. تتبع جميع استجابات الأخطاء نفس البنية { error, message, request_id }.

أفضل ممارسات التكامل

قم بتخزين العمليات الحسابية المتكررة محليًا كلما أمكن ذلك لتقليل استدعاءات واجهة برمجة التطبيقات (API). بالنسبة لسير عمل البطولة، استخدم نقطة النهاية المجمعة بدلاً من تقديم طلبات متسلسلة للعبة واحدة. قم دائمًا بتضمين معلمة ملف القواعد بشكل صريح بدلاً من الاعتماد على الإعداد الافتراضي للخادم، بحيث يظل التكامل الخاص بك محددًا حتى عندما تضيف واجهة برمجة التطبيقات ملفات تعريف جديدة.

بالنسبة لبرامج النادي ولوحات معلومات التدريب، فكر في تخزين كل من النتائج المحسوبة وإصدار ملف تعريف القواعد حتى تتمكن من التدقيق أو إعادة الحساب لاحقًا في حالة تغيير قواعد الاتحاد. وهذا مهم بشكل خاص بالنسبة لسير عمل التقارير الرسمية حيث تكون الدقة التاريخية مهمة.