الخلاصة

  • يبين Deprecation في RFC 9745 متى سيصبح المورد مهملاً أو متى أصبح كذلك، ويشير Sunset في RFC 8594 إلى الوقت الذي يرجح فيه أن يتوقف URI عن الاستجابة؛ وكلاهما تلميح محدود بالمورد افتراضياً، لا دليلاً على اكتمال الترحيل.
  • ينبغي لسجل قطع ترحيل العميل أن يربط الترويسات والروابط المرصودة بالنطاق المصرح به والبديل ومالكي الاستخدام وقياسات الحركة واختبارات التوافق والاستثناءات وشروط الرجوع والمشاهدة اللاحقة للإيقاف.

التحليل

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

توفر RFC 9745 صيغة مشتركة لهذا الإعلان. قيمة Deprecation هي تاريخ وفق Structured Fields. إذا كان التاريخ مستقبلياً فهو موعد سريان الإهمال المزمع، وإذا كان ماضياً فهو موعد سريان الإهمال بالفعل. وتضع الوثيقة حداً مهماً للمعنى: إعلان الإهمال لا يغير سلوك المورد بذاته. يمكن أن يستمر المورد في الرد بالطريقة نفسها، وإن لم يعد من الآمن افتراض بقاء سلوكه كما كان قبل التاريخ.

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

أما Sunset في RFC 8594 فيجيب عن مرحلة أخرى: الوقت الذي يتوقع فيه أن يصبح URI غير مستجيب. وهو بدوره تلميح، فلا يضمن أن يبقى المورد متاحاً حتى الموعد ولا أن يختفي فور حلوله. كما لا يقول هل ستكون النتيجة خطأ أم إعادة توجيه أم تعذر اتصال. وعند جمعه مع Deprecation، تشترط RFC 9745 ألا يسبق تاريخ Sunset تاريخ الإهمال. هذا يمنع ترتيباً زمنياً متناقضاً، لكنه لا يثبت أن أي عميل أصبح مستعداً.

المورد المرصود ليس النطاق كله

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

لذلك تثبت الملاحظة أمراً دقيقاً وضيقاً: هذا URI أعاد هذه القيمة في هذا الوقت. ولا يجوز رفعها من دون دليل إلى جميع الطرق والمناطق والحسابات. كما أن غياب الترويسة عن مسار واحد لا يثبت خروجه من قرار أُعلن في موضع آخر.

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

اكتشاف البديل لا يجيز التحويل التلقائي

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

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

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

مكونات سجل القطع

يبدأ السجل بحزمة الإعلان: URI القانوني، وقت ومصدر الرصد، بصمة الرد، قيمتا Deprecation وSunset والروابط المرتبطة. ثم يذكر النطاق المعلن وصاحب السلطة في توسيعه. إذا تعارضت صفحات المزوّد أو أقوال فرقه، يبقى التعارض ظاهراً ولا يتحول إلى عبارة مطمئنة مثل «الخدمة كلها».

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

الحزمة الثالثة هي سجل المستهلكين. لكل عميل معروف مالك ودرجة أهمية وآخر استخدام مرصود ومصدر قياس وحالة انتقال وموعد قرار تالٍ. ويلزم أن تصاحب انعدام الحركة ملاحظة عن مجال الرؤية. قد تخفي الذاكرة المؤقتة أو الوسيط أو مهمة فصلية أو بيئة طوارئ أو منطقة أخرى استخداماً حقيقياً.

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

الحزمة الأخيرة لقرار القطع: مجموعة تجريبية، معايير نجاح، سبب إيقاف التجربة، هدف الرجوع، محفز الرجوع وآخر وقت يمكن فيه الرجوع بأمان. وبعد الموعد يسجل الفريق ما أعاده المورد القديم فعلاً. تأجيل الإيقاف حقيقة جديدة لا تمحو الإعلان السابق، والتوقف المبكر انحراف يجب ألا يختفي خلف وجود تاريخ منشور.

لكل قرار ساعته

يؤرخ Deprecation حكماً على مكانة المورد. ويعبر Sunset عن توقع لتوفره. لكل عميل تاريخ مستهدف، ولكل استثناء نهاية، وللقدرة على الرجوع حد تقني، وللانقطاع الفعلي وقت لا يُعرف إلا بعد وقوعه.

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

المصادر

  1. RFC 9745 — The Deprecation HTTP Response Header Field
  2. RFC 8594 — The Sunset HTTP Header Field
  3. سجل IANA لأنواع علاقات الروابط