الخلاصة

  • حددت RFC 7807 الصادرة في مارس 2016 شكلاً مشتركاً للأخطاء بصيغتي JSON وXML، وجعلت URI في الحقل type المعرّف الأساسي لنوع المشكلة.
  • حلّت RFC 9457 الصادرة في يوليو 2023 محلها، وبيّنت كلفة العنوان النسبي وتغيير هوية النوع وكيفية عرض مشكلات متعددة.
  • يضم سجل IANA الرسمي الأنواع العامة القابلة للاشتراك. وإذا غاب type كانت قيمته المفترضة about:blank، فلا يضيف معنى يتجاوز حالة HTTP.

الرمز الواحد يخفي قرارات مختلفة

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

في المثال المنشور، يرد 403 على طلب شراء، ويصف الجسم نوع نقص الرصيد، وعنواناً للبشر، وتفاصيل تلك الواقعة، ومؤشراً إلى حدوثها، وحقولاً إضافية عن الرصيد والحسابات. الصيغة application/problem+json مشتركة، وكذلك بديل XML؛ أما معنى نقص الرصيد فيبقى من عمل الجهة التي تنشر الواجهة. المواصفة رتبت مكان العبارة ولم تكتب سياسة متجر بعينه.

حقل type هو نقطة الارتكاز للبرنامج. نص 2016 طلب من المستهلك استعمال سلسلة URI بوصفها هوية نوع المشكلة. title خلاصة للقارئ ويمكن أن تتبدل لغتها. detail شرح لهذه الواقعة، وليس قاموس أوامر يُفكّك بكلمات مفتاحية. البحث عن لفظة «رصيد» داخل الجملة ينهار عند تحريرها أو ترجمتها. الاعتماد على URI أوضح، لكنه يربط العميل بوعد المشغّل بأن يحفظ معنى العنوان.

هناك عنوان ثانٍ هو instance. يشير إلى حدوث واحد، بينما يشير type إلى فئة يمكن أن تتكرر. قد يفشل شراءان للسبب نفسه ويحصل كل منهما على مرجع مختلف للدعم أو التتبع. يقرر العميل تصرفه من الفئة؛ ويبحث فريق الدعم عن الحادثة من المرجع الفردي. تسمية الاثنين «معرّف خطأ» تمحو الفرق بين قاعدة قابلة لإعادة الاستخدام وسجل واقعة.

فراغ مقصود

إذا لم تذكر الاستجابة type، افترضت المواصفة about:blank. الاسم الجاف له وظيفة دقيقة: المشكلة لا تحمل دلالة إضافية فوق رمز الحالة. رد 404 محاط بجسم JSON يظل 404. التنسيق الموحد لا ينتج وحده فئة جديدة يمكن للآلة أن تتخذ على أساسها قراراً. على المشغّل أن يسمي الفئة ويشرحها ويحافظ عليها إن أراد معاملة مختلفة.

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

تغيير العنوان يغير الهوية

أبقت RFC 9457 الصادرة في 2023 على البنية، وشرحت مشكلة URI النسبية. الاسم example-problem يمكن أن يُحل إلى موردين مختلفين بحسب عنوان الاستجابة. لذلك توصي بعناوين مطلقة متى أمكن. وتسمح أيضاً بعناوين لا يمكن فتحها. إذا قرر الناشر لاحقاً استبدالها بعنوان قابل لفتح صفحة توثيق، فقد أعطى النوع هوية جديدة؛ قد لا يعرفها العملاء القدامى. قرار تسمية صغير يتحول إلى كلفة توافق طويلة.

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

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