الخلاصة

  • تقترح مسودة API v3 من PeeringDB خدمة عامة للقراءة فقط عبر مواقع متعددة، مع أهداف للتوافر وحداثة البيانات.
  • ما زال النص مطروحاً للتعليق، لا إعلاناً عن الإطلاق: قواعد الوصول والتفاصيل الكاملة للواجهة لم تُحسم، ولا توجد قياسات لأداء الإنتاج.

تضع المسودة ساعةً لخدمة API مستقبلية، لكنها لا تحدد موعداً لإتاحتها. وثيقة PeeringDB المؤرخة في 18 سبتمبر تستهدف توافراً لا يقل عن 99.95%، وأن تظهر 99% من التغييرات خلال دقيقة واحدة، وألا تتجاوز استجابة أحدث البيانات 15 دقيقة، بما في ذلك تأخر التخزين المؤقت. ولا تحدد الوثيقة موعد التنفيذ؛ إذ تصف نفسها بأنها دعوة أولى للتعليق والمراجعة.

تشرح مادة APNIC عن تحديث PeeringDB، المنشورة في 7 أكتوبر، دوافع التصميم. يذكر Leo Vegoda، مدير المنتجات، هدفين: فصل القراءة عن الكتابة لإتاحة الخدمة من مواقع عديدة، وتحسين كفاءة الاستعلام عن العلاقات الشائعة بين السجلات. كما يطلب آراء مستخدمي الواجهة قبل التنفيذ. أما المواصفات التفصيلية فترد في وثيقة PeeringDB نفسها؛ APNIC جهة النشر وليست مشغّل الواجهة.

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

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

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

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

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

المصادر