ماذا يجب التحقق منه عند تقييم Order API
الإجابة المباشرة
عند تقييم Order API، ركّز على ما تفعله الواجهة فعليًا بالأوامر، وكيف يمكنك تأكيد النتائج، وأين قد يختلف السلوك عن توقعاتك. اجعل قائمة التحقق موضوعية: افصل بين الآليات الثابتة (بنية الطلب/الاستجابة، ودلالات دورة الحياة) والظروف المتغيرة (حركة السوق، والتكاليف، وجودة التنفيذ، والقواعد المحلية). وبما أن النتائج تعتمد على عوامل خارجية، تعامل مع الأمثلة على أنها افتراضات وليست تنبؤات.
كيف تعمل Order API (الآلية والتعريف)
Order API هي واجهة برمجية تُستخدم لإرسال أوامر التداول وتعديلها وإلغائها، وكذلك لاسترجاع معلومات عن حالة دورة حياتها. عمليًا، غالبًا ما تتعامل مع:
- طلب الأمر: البيانات التي ترسلها (مثل نوع الأمر، والجهة/الجانب side، والكمية، وtime-in-force، وأي معرّفات مطلوبة).
- التنفيذ والإقرار (acknowledgement): الاستجابات التي تتلقاها (قبول، رفض، أو أخطاء).
- تحديثات حالة الأمر: كيف يبلّغ المزود عن التغييرات مع مرور الوقت (مفتوح، ملء جزئي، ممتلئ، مُلغى، منتهي/منقضي، مرفوض).
- معرّفات المصالحة (reconciliation): الحقول التي تتيح لك مطابقة نيتك مع نتائج يبلّغ عنها المزود (مثل client order IDs وprovider order IDs، إذا كانت مدعومة).
خطوة تقييم رئيسية هي ترجمة التوثيق إلى نموذج حالة صريح لنظامك: ما هي الحالات الموجودة، وكيف تحدث الانتقالات، وما الضمانات (إن وجدت) التي تقدمها الواجهة حول ترتيب الأوامر وإعادة المحاولة وتحديثاتها. الآليات الثابتة هي ما يمكنك الاستدلال عليه من المواصفة؛ أما الظروف المتغيرة فهي كل ما يمكن أن يتغير بين لحظة الطلب والتأكيد.
قائمة التحقق من العناية الواجبة (afvinkpunten)
استخدم العناصر أدناه لبناء عملية تحقق قابلة للتكرار.
1) الإدخال والدلالات (ما الذي ترسله)
- أكد الحقول المطلوبة وقيود البيانات (أنواع الأوامر المسموح بها، والحد الأدنى/الأقصى للأحجام، وقيم time-in-force الصحيحة).
- وثّق كيف تفسّر الواجهة وحدات القياس وقواعد التقريب. حدّد افتراضاتك أنت للكمية والدقة، وكيف يتم التعامل مع مبالغ “base” مقابل “quote”.
2) idempotency وحماية التكرار (تمنع عدم تطابق الحالة)
- تحقق مما إذا كانت الواجهة تدعم طلبات idempotent أو استراتيجية موثقة لإعادة المحاولة بعد timeouts.
- تحقّق من كيفية التعامل مع الطلبات المكررة عند إرسال نفس الطلب مرة أخرى (نفس client ID مقابل طلب جديد). هذا مهم لأن منطق إعادة المحاولة شائع في الأنظمة الآلية.
3) دورة حياة الأمر والمصالحة (دليل أو توثيق)
- تحقق من دورة حياة الأمر كاملة: ما هي الحالات التي يمكن أن تحدث، وكيف يتم الإبلاغ عن الانتقالات.
- أكد الحقول التي تحتاجها للمصالحة (معرّفات الأوامر، الطوابع الزمنية، الكميات المملوءة، الكمية المتبقية، وأسباب الرفض).
- حدّد معايير “الانتهاء” لديك (مثلًا: تعتبر الأمر مغلقًا عندما تتلقى حالة نهائية مثل filled/cancelled/rejected/expired—وفقًا للدلالات الموثقة لدى المزود).
4) التحديثات ونموذج التسليم (ما الذي يمكنك ملاحظته)
- حدد ما إذا كانت معلومات الحالة تأتي عبر الاستقصاء الدوري (polling)، أو البث/الويب هوكس (streaming/webhooks)، أو كليهما.
- إذا كانت التحديثات غير متزامنة، فراجع الضمانات حول ترتيب الأحداث (event ordering) واكتمال الأحداث (event completeness). يجب أن تتعامل منطق المصالحة لديك مع التحديثات المفقودة أو المتأخرة كسيناريو صريح.
5) التكاليف وافتراضات التنفيذ (ما الذي يمكن أن يتغير)
- حدد أي تكاليف وآثار تنفيذ يمكن أن تغيّر النتائج بين لحظة الطلب والحالة النهائية: الرسوم، والسبريد (spreads)، والانزلاق السعري (slippage)، والملء الجزئي، وlatency.
- عند توضيح مثال، اذكر الافتراضات (مثلًا: “افترض أن الرسوم X وأن عمليات الملء تحدث في تنفيذ واحد”) ثم لاحظ أن الظروف الفعلية قد تختلف.
6) أوضاع الفشل (rode vlaggen)
ابحث واختبر أوضاع الفشل الشائعة هذه:
- الأوامر المرفوضة (أخطاء التحقق من الصحة، أو عدم كفاية الصلاحيات، أو معلمات غير صالحة).
- timeouts والأخطاء العابرة (قد يعيد عميلك المحاولة بينما يكون المزود قد عالج الطلب بالفعل).
- الملء الجزئي (يصبح الأمر منفذًا جزئيًا، ما يتطلب منطقًا للكمية “remaining”).
- حالة غير متسقة (يرى نظامك مصدر حالة واحد بينما المصدر الآخر متأخر).
إذا لم يحدد التوثيق بوضوح كيف تتصرف هذه الحالات، فاعتبر ذلك علامة حمراء وخطط لمصالحة ومراقبة تحفظية.
القيود والمخاطر (ما الذي قد يحدث خطأ)
تنفيذ الأوامر ونتائج حالة الأوامر تعتمد على ظروف السوق وسلوك المزود، وهي ليست قابلة للتحكم بالكامل. العلاقات التاريخية لا تضمن النتائج المستقبلية، وحتى المواصفات الدقيقة قد تفشل تحت الضغط (تذبذب مرتفع، مشكلات الشبكة، أو صيانة من جانب المزود). تشمل القيود المادية التي يجب الاعتراف بها صراحةً:
- عدم اليقين بين النية والتنفيذ: الإقرار (acknowledgement) لا يعني بالضرورة التنفيذ النهائي.
- نتائج غير ذرّية (Non-atomic outcomes): يمكن أن يؤدي الملء الجزئي والإلغاءات اللاحقة إلى إنشاء عدة حالات لتعليمـة واحدة.
- فجوات في قابلية الملاحظة (Observability gaps): قد تؤدي التأخيرات أو التحديثات المفقودة إلى أن يفسر نظامك الحالة الحالية بشكل غير صحيح.