الخلاصة

  • تفصل وثيقة OpenAPI الحالية لدى APNIC طلبات دفعات RDNS والمسارات وASPA إلى مصفوفات create وupdate وdelete، بينما لا يعلن عنصر النتيجة سوى status وmessage.
  • الضابط المتناسب ليس كشف سجل المعاملة، بل وصلة صغيرة ومطلوبة: فهرس أو مفتاح عميل معتم، وفئة العملية، ورمز نتيجة ثابت، ومرجع آمن إلى المورد حين يكون ذلك مناسباً.

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

يصف العقد المنشور ما قد يوجد داخل كل نتيجة. للحقل status ثلاث قيم: success أو failure أو notification. ويصحبه نص حر في message. لكنه لا يذكر اسم مصفوفة الطلب، ولا ترتيب العنصر فيها، ولا مفتاحاً يرسله العميل ويستعيده، ولا معرّف مورد أو location. كما لا تقول نسخة OpenAPI المفحوصة إن النتيجة الأولى تعود إلى أول عنصر إنشاء، أو إن نتائج التعديل تأتي قبل الحذف، أو كيف تدخل الإشعارات في الترتيب.

هذه صورة افتراضية لا وصفاً لسلوك الخدمة الحية. لم تُرسل في هذا البحث دفعة موثّقة، ولم يظهر بلاغ من عضو عن خلط نتيجة بعنصر آخر. قد يحافظ التنفيذ على الترتيب دائماً. وقد تسمّي الرسالة المورد بوضوح. وقد تحمل سجلات APNIC الداخلية وصلةً دقيقة. الدليل أضيق من ذلك كله: الإصدار 0.0.2 من وثيقة OpenAPI 3.0.0 العامة لا يعلن تلك الوصلة.

ابدأ بأقوى دفاع عن APNIC

بنت APNIC في الواجهة قدراً مهماً من المساءلة بالفعل. فعمليات POST وPUT وDELETE موصوفة بوصفها مهام غير متزامنة. ويمكن للمهمة الاحتفاظ بالطلب الأصلي ووقت تقديمه، ثم حمل استجابة فيها مدة المعالجة ورمز HTTP والمحتوى. يستطيع العميل حفظ رابط المهمة ووضع المدخل والنتيجة جنباً إلى جنب.

والدفعة ليست قيمة منطقية مبهمة. تقول الوثائق إن results تحمل عناصر منفصلة للأفعال، مع إشعارات حيث يلزم. وتذكر المقدمة أن الدفعات تُطبّق معاملاتيّاً عندما يكون ذلك ممكناً، وأن التفاعلات التي لا تمس Whois تُعالج، بوجه عام، على نحو معاملي. كما تتيح الواجهة عمليات GET والقوائم، وتقابل وظائف في MyAPNIC، ولها تاريخ اختبار وهاكاثون وعروض منتج وقنوات تغذية راجعة عامة وخاصة.

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

لذلك لا يقول هذا المقال إن APNIC تعيد ترتيب النتائج، أو تربطها بالفعل الخطأ، أو تفقد عملية، أو تنفذ دفعة جزئياً، أو تدفع الأعضاء إلى إعادة إرسال خطرة. ولا يطلب بيانات اعتماد أو محتوى سجل أو يوميات معاملات. السؤال الوحيد هو: ما الذي يستطيع تكامل مستقل أن يعتمد عليه من العقد الآلي المنشور؟

للطلب عناوين أدق من الإجابة

عند قراءة المخططات جنباً إلى جنب يظهر عدم التناظر. فطلبات دفعات RDNS والمسارات وASPA موزعة إلى مصفوفات مسمّاة: create وupdate وdelete. ويختلف شكل العنصر بحسب عائلة المورد والعمل. قد يحمل حذف مسار معرّفاً قائماً، ويحدد حذف RDNS نطاقاً، وقد يضم تحديث ASPA معرّفاً وASN للعميل ومجموعة ASN للمزوّدين.

هذا يمنح كل فعل عنواناً طبيعياً داخل طلب العميل: عائلة المورد، ونوع العملية، وموضعه في المصفوفة. يعرف البرنامج أنه أرسل، مثلاً، delete[1].

أما مخطط batch-response المشترك فيحتوي مصفوفة results، ويعلن داخل عنصرها خاصيتين بالضبط: status وmessage. الحالة تصف النتيجة العامة، لكن النص ليست له قواعد نحوية آلية في المخطط. لا يوجد حقل يقول إن هذه الإجابة تخص delete[1].

لا يجعل ذلك الاستجابة خاطئة؛ بل يجعل الصلة ضمنية. إذا كان ترتيب المصفوفات هو الذي يوفرها، فذلك الترتيب جزء من سلوك الواجهة، وينبغي أن يكون قابلاً للقراءة والاختبار في العقد نفسه.

تضيف قواعد OpenAPI ملاحظة ثانية. وجود الخاصية في كائن لا يجعلها إلزامية؛ تصبح كذلك عندما يوردها المخطط داخل مصفوفة required. ولا تتضمن مخططات batch-response وtask وtask-link وsuccess-response في الوثيقة المفحوصة مصفوفة required على المستوى الأعلى. وبذلك يصف الملف شكلاً مسموحاً، لا حداً أدنى تضمنه المواصفة.

مرة أخرى، قد تعيد الخدمة كل هذه الحقول في كل مرة. الملاحظة تخص ما يستطيع مولّد عميل أو اختبار عقد استنتاجه من الملف وحده.

لا يصبح الترتيب ضابطاً إلا إذا نُص عليه

لنضع حالة اختبار فقط: ثلاث عمليات إنشاء وحذفان، ثم نتائج بالترتيب success وfailure وsuccess وsuccess وnotification. من دون قاعدة معلنة يمكن تصور أكثر من قراءة. قد تأتي النتائج بعد جمع مصفوفات الطلب بالترتيب. وقد يكون الإشعار صفاً مستقلاً. وقد تسمّي رسالة الفشل مورداً بعينه. وقد يصف فشل واحد رجوع مجموعة معاملية كاملة.

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

تقلّص الوصلة الواضحة أيضاً نطاق إعادة المحاولة. إذا عرف العميل أن delete[1] فشل في التحقق وأن create[0] نجح، يستطيع مراجعة الهدف الفاشل من دون إعادة الناجح. وإذا كانت الدفعة ذرية، يمكن للنتيجة أن تقول إن مجموعة المعاملة رجعت، بدلاً من اختراع خمس نتائج مستقلة. وإذا كان المطلوب هو الاستعلام لا الإرسال، يمكن إرفاق التوجيه بالعنصر أو المجموعة المقصودة.

الفائدة ليست أكبر كمية من القياس. إنها حصر القرار. معرّف صغير يمنع الشك المحلي من التحول إلى إعادة تشغيل الدفعة كلها.

المهمة غير المتزامنة تحفظ السؤال لكنها لا تحل الوصلة

غلاف المهمة مفيد لأن المعالجة تستمر بعد التبادل الأول. يوضح RFC 9110 أن 202 Accepted يعني قبول الطلب للمعالجة، لا اكتمالها بنجاح. وتذهب APNIC أبعد بإتاحة مهمة يمكن أن تحمل الاستجابة لاحقاً.

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

يوفر RFC 7240 ولغة respond-async، كما يوفر Google AIP-151، تصاميم مقارنة للعمل طويل المدة؛ وهما ليسا حكمين بأن APNIC خالفت قاعدة. ويقدم RFC 9457 بنية لمشكلات HTTP، لكنه لا يفرض طريقة ترابط دفعات APNIC. هذه مراجع تصميمية، فيما يظل دليل هذه المسألة هو مخطط APNIC نفسه.

يدفع العملاء التكلفة بطرق غير متساوية

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

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

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

خريطة رقيقة للنتيجة

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

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

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

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

المواصفة جزء من سطح التشغيل

أطلقت APNIC واجهة السجل كي يؤتمت الأعضاء أعمالاً كانت تتم عبر MyAPNIC. ويبين العرض المبكر والهاكاثون وعروض المنتج مؤسسةً تشجع البرمجيات على الاعتماد على الواجهة. لذلك ليست المواصفة شرحاً جانبياً؛ إنها الحد الذي تُبنى منه الشفرة والاختبارات والتوقعات التشغيلية.

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

لا تحتاج APNIC إلى إثبات وقوع ضرر كي تصلح الحافة. يكفي أن تمنح كل نتيجة عنواناً يعود إلى السؤال. عندئذ تصبح success وfailure وnotification حالات تستطيع الآلة التصرف على أساسها، لا بطاقات يحتاج الإنسان إلى موضعتها بالتخمين.

المصادر