الخدمة تعمل، لكن ردّها بدأ يطلب الرحيل

الخلاصة

• حددت RFC 9745 في مارس 2025 حقل الاستجابة Deprecation بقيمة تاريخ وفق Structured Fields. دخول المورد مرحلة التقادم لا يغير سلوكه فوراً.
• يمكن لعلاقة Link المسماة deprecation أن تقود إلى سياسة الانتقال قبل ظهور الحقل المؤرخ. أما RFC 8594 لعام 2019 فقد عرّفت Sunset لوقت يُتوقع أن يتوقف فيه المورد عن الاستجابة.
• ينطبق الإشعار أولاً على المورد المحدد في الاستجابة. توسيع النطاق يحتاج قاعدة يعلنها ناشر الواجهة؛ وسجلات ردود مؤرخة تكشف أين استخدم الحقل فعلياً.

جواب ناجح يحمل إعلان تقاعد

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

وضعت RFC 9745 الإشعار في استجابة HTTP. يصف Deprecation المورد الذي تحدده تلك الاستجابة، ويحمل تاريخاً وفق صيغة Structured Fields. مثال المواصفة Deprecation: @1688169599 يقابل 30 يونيو 2023 الساعة 23:59:59 بالتوقيت العالمي. إذا كان التاريخ في المستقبل يبدأ التقادم عنده؛ وإذا مضى فقد بدأ. يستطيع المورد أن يواصل الرد في الحالين.

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

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

الوثيقة قد تسبق عقرب الساعة

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

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

ساعة للتقادم وأخرى للإغلاق

عرّفت RFC 8594 في مايو 2019 حقل Sunset لوقت يُتوقع أن يصبح فيه المورد غير مستجيب، بصيغة تاريخ HTTP المعتادة. Deprecation يصف مرحلة تسبق ذلك: المورد يعمل، لكن مقدم الخدمة لم يعد يشجع بناء اعتماد جديد عليه. الأول يخص قرار الاستثمار في المورد؛ الثاني يخص أفق توفره المتوقع.

تسمح RFC 9745 بإرسال الحقلين وتشترط ألا يسبق تاريخ Sunset تاريخ Deprecation. يضع مثالها التقادم في 30 يونيو 2023 والتوقف المتوقع بعد عام. عكس الترتيب يعني إعلان الإغلاق قبل الإعلان عن التخلي التدريجي، وهو جدول لا يساعد أحداً على التخطيط. تختلف الكتابة أيضاً: تاريخ Structured Fields مع @ في Deprecation، وتاريخ HTTP في Sunset.

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