الخلاصة

  • تجعل RFC 9110 رمز الطريقة المصدر الأساسي لدلالة الطلب: يبين غرض العميل وما يعده نجاحا، بينما يقرر كل مورد مستهدف بصورة مستقلة هل يعرف الطريقة وينفذها ويسمح بها.
  • تصف Safe ما طلبه العميل، لا غياب كل أثر جانبي. وتصف Idempotent الأثر المقصود عند تكرار الطلب نفسه، لا تطابق الردود أو السجلات أو كل النتائج الخارجية.
  • يحتاج التشغيل الحساس إلى إيصال يجمع الطريقة والهدف وصاحب الهوية الموثق وسياسة التفويض والشرط السابق وعدم اليقين بشأن المحاولة الأولى ودليل التكرار التطبيقي ومن أعاد المحاولة والرد والحالة النهائية والآثار اللاحقة.

تبدو GET وPUT وDELETE أوامر. لكنها في HTTP أقرب إلى تصريحات عامة عن المقصود. يستطيع cache أن يميز الاسترجاع من التغيير، ويستطيع gateway أن يطبق حدا، ويستطيع العميل أن يفكر في إعادة طلب ضاع رده، من دون أن يرى أي منهم قاعدة بيانات التطبيق.

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

الدلالة المشتركة تنتهي قبل باب المورد

تقول RFC 9110 إن الطريقة تبين الغرض من الطلب والنتيجة التي يتوقعها العميل عند النجاح. تطلب GET تمثيلا حاليا. وتطلب PUT إنشاء الحالة الممثلة أو استبدالها في هدف اختاره العميل. أما DELETE فتطلب إزالة الصلة بين URI والوظيفة الحالية؛ ولا تتعهد بمحو كل نسخة مادية.

ينبغي أن تحتفظ الطريقة المعيارية بالدلالة نفسها عبر الموارد. لذلك تستطيع المكونات العامة أن تستنتج قدرا محدودا من السلوك. لكن المورد يقرر هل ينفذ هذه الدلالة ويسمح بها. الطريقة غير المعروفة أو غير المنفذة تقود إلى 501. والطريقة المعروفة والمنفذة التي لا يدعمها الهدف تقود إلى 405، مع Allow الذي يعرض الطرق المدعومة حاليا.

لا يمثل Allow قائمة أصحاب الحق. قد يدعم مستند PUT ولا يجيزه إلا للمحررين. المصادقة تحدد principal، والتفويض يطبق سياسة على الهوية والفعل والهدف، ودعم الطريقة يصف قدرة المورد. هذه ثلاثة قرارات يجب ألا يبتلع أحدها الآخر.

يوضح مبدأ Minimum Initial Specification عند Heng Lu هذا الحد: توضع في الطبقة المشتركة فقط الدلالة الصارمة اللازمة للتشغيل البيني، وتبقى قرارات العمل لدى من يشغل المورد. سجل IANA دفتر مفردات، لا خادوم صلاحيات مركزي.

Safe يحدد المسؤولية ولا يلغي الأثر

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

هذا الفصل يسمح للزواحف وفحص الروابط وprefetch بالعمل. وفي المقابل يفرض على مالك المورد ألا يخفي فعلا خطرا داخل طريقة آمنة. لا يجوز أن يؤدي GET إلى page?do=delete لحذف محتوى. وجود كلمة delete في query لا يحول الزاحف إلى صاحب نية في الإزالة.

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

Idempotent تثبت تقارب الأثر المقصود

تكون الطريقة idempotent إذا كان الأثر المقصود لطلبات متطابقة متعددة هو أثر طلب واحد. تشمل RFC 9110 PUT وDELETE والطرق الآمنة. ويظل للخادوم أن يسجل كل محاولة، أو يحفظ revisions متعددة، أو يرسل ردا مختلفا.

قد تنجح DELETE الأولى وتجد الثانية أن المورد غائب. يختلف الرد وتبقى الحالة المقصودة واحدة. وقد تصل PUT المكررة إلى الحالة نفسها مع تاريخ أو ETag مختلف.

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

لذلك نحتاج operation key وحالة commit وإزالة التكرار لكل نظام لاحق ومسار تعويض. الصفة في HTTP بداية للاستدلال وليست معاملة موزعة كاملة.

إعادة المحاولة تعالج جهلا بما حدث أولا

إذا انقطع الاتصال قبل قراءة الرد، فقد لا يعرف العميل هل وصل الطلب أو طُبق أو ضاع الرد بعد التنفيذ. تكون إعادة الطريقة idempotent معقولة لأن المحاولة الثانية يفترض أن تصل إلى الأثر المقصود نفسه حتى لو نجحت الأولى.

لكن RFC لا تمنح حلقة بلا نهاية. لا ينبغي للعميل إعادة طريقة غير idempotent تلقائيا إلا إذا عرف أن العملية المحددة متقاربة في ذلك المورد أو استطاع إثبات أن الطلب الأول لم يطبق. ولا يجوز للproxy إعادة هذا النوع تلقائيا، ولا ينبغي للعميل متابعة إعادة تلقائية فشلت بمحاولات تلقائية أخرى.

يعتمد القرار على نقطة الانقطاع والهدف ومحتوى الطلب والشرط السابق وoperation key وحالة يمكن الاستعلام عنها وعدد المحاولات وbackoff. قد يكون POST آمنا للاستعادة بمفتاح مستقر. وقد تكون PUT خطرة حين لا تضبط آثارها الخارجية.

يعيد Running-Code Primacy الاختبار إلى السلوك القابل للتحقق: هل تتقارب النسخ فعلا؟ هل يمكن قراءة وضع commit؟ هل تبقى العواقب محدودة؟ التسمية لا تكفي من دون تشغيل يثبتها.

If-Match يحمي النسخة ولا يثبت صاحبها

يشترط If-Match أن يبقى ETag الحالي مطابقا لما عرفه العميل قبل تنفيذ التغيير. إذا فشل الشرط فلا تطبق الطريقة، ويكون الرد المعتاد 412. هكذا لا تمحو نسخة قديمة عملا أحدث.

معرفة ETag ليست اعتماد هوية. لا تمنح حق الكتابة. كما أن امتلاك الحق لا يجعل ETag القديم حديثا. يجيب التفويض عن سؤال من يستطيع الفعل، ويجيب الشرط عن سؤال هل الحالة ما زالت كما افترضها الطلب. ينبغي حفظ سبب كل رفض.

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

QUERY تجعل الصفة الخاصة مرئية للمكونات العامة

عرّفت RFC 10008 في يونيو 2026 طريقة QUERY، ومؤلفوها Julian Reschke وJames Snell وMike Bishop؛ وهي ليست من تأليف Fielding. تحمل QUERY محتوى مثل POST لكنها تعلن استعلاما آمنا وidempotent. ويسجل IANA الصفتين بقيمة yes.

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

لا يعني التسجيل انتشارا. قد لا يمرر gateway الطريقة، وقد يرد الخادوم 501، أو المورد 405، أو يرفض التفويض. سجل IANA ledger للدلالة، وليس ACL.

مساهمة Fielding حدود واجهة وليست ملكية

يصف IETF Datatracker الذي روجع في 31 أغسطس 2026 Roy T. Fielding بأنه كبير العلماء الرئيسيين في Adobe، وأحد مؤسسي The Apache Software Foundation، وصاحب REST، ومساهم في HTTP وURI وURI Templates. يسجل 18 RFC ودور مراجع في HTTP Directorate. كما توثق UC Irvine درجاته ومساهماته في الويب وApache.

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

لـRFC 9110 ثلاثة محررين: Fielding وMark Nottingham وJulian Reschke. HTTP عمل جماعي متراكم. وتنسب RFC 10008 إلى مؤلفيها. يجعل التوقيع المساهمة قابلة للتتبع، ولا يجعل البروتوكول ملك شخص واحد.

يبدأ إيصال العملية حيث تنتهي الكلمة

سجل الطريقة وURI وorigin، ثم principal الموثق ونطاق الاعتماد، وقرار دعم المورد، وسياسة التفويض وإصدارها، وETag أو الشرط، وhash المحتوى، والأثر المقصود. عند الفشل، أضف آخر نقطة إرسال مؤكدة، وإمكان تطبيق المحاولة الأولى، ومفتاح العملية، ومن أعادها وسببها وعددها وفترة الانتظار.

اختم بالرد والحالة المعاد قراءتها والآثار اللاحقة والتعويض وما لا يمكن عكسه. عندئذ تجيب كل طبقة عن سؤالها: الطريقة عن مقصد العميل، والمورد عن قدرته، والتفويض عن حق principal، والشرط عن حداثة الحالة، ودليل الاستعادة عن جدوى التكرار.

الطريقة تسمي النية. ولا تمنح الإذن.

المصادر