الخلاصة

  • تحمل QUERY عبارة الاستعلام في محتوى الطلب، وهي مسجلة كطريقة آمنة ومتكررة الأثر. هذا التوصيف التزام على المنفّذ، وليس شهادة تلقائية بأن أي معالج خالٍ من آثار الأعمال.
  • يجب أن يدخل المحتوى وبياناته الوصفية في مفتاح الذاكرة المؤقتة. توزّع الإعادة والتحويلات الشرطية وAccept-Query وURI المورد المكافئ سلطات مختلفة بين العميل والوسيط والمنشأ.

لنفترض أن منصة بيانات تستقبل مرشحاً مركباً يضم شروطاً متداخلة وحقولاً مختارة. GET مناسب للقراءة، لكن RFC 9110 لا يعطي معنى عاماً للمحتوى المستلم في طلب GET. أما POST فيحمل المحتوى بسهولة، إلا أن انقطاع الاتصال بعد الرفع لا يترك للعميل افتراضاً عاماً بأن التكرار لن يكرر عملاً تجارياً.

نُشر RFC 10008 في يونيو 2026 كمعيار مقترح ليملأ هذه الفجوة. يطلب QUERY من المورد الهدف معالجة استعلام يمثله محتوى الطلب. المحتوى إلزامي، ونوع الوسائط يحدد صيغته، ويكوّن المحتوى مع البيانات الوصفية ذات الصلة هوية السؤال. تسجل IANA طريقة QUERY على أنها آمنة ومتكررة الأثر، وتسجل Accept-Query حقلاً دائماً.

ليست QUERY طلب GET ذا body، وليست POST باسم جديد. الأمان يعني أن الأثر المقصود قراءة لا تغيير لحالة العمل. وتكرار الأثر يعني أن تنفيذ الطلب ذاته مرات عدة يحقق الأثر المقصود نفسه لتنفيذ واحد، لا أن تكون بايتات الرد متطابقة. حجز سعة أو استهلاك حق أو اعتماد عملية ليس استعلاماً آمناً حتى لو منع البرنامج التكرار الثاني.

خاصية الطريقة إذن بالاعتماد عليها

قد يؤتمت العميل طريقة آمنة، وقد تعيد مكتبة النقل طريقة متكررة الأثر بعد فشل لا تعرف عند أي نقطة وقع، وقد يطبق cache قواعده على طريقة يفهمها. عندما يعلن المنشأ QUERY فإنه يمنح هؤلاء أساساً لاتخاذ القرار.

لذلك لا يكفي وصف route أو وثيقة API. يجب أن يربط الدليل الطريقة وبصمة المحتوى ونوع الوسائط وسياق الهوية وتنفيذ التطبيق والآثار والتمثيل المسلّم. عند إعادة المحاولة ينبغي أن يجيب السجل: هل وصلت المحاولة الأولى إلى منطق العمل، وهل صنعت الثانية تغييراً كان الأمان يمنعه؟

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

المحتوى جزء من هوية cache

يفرض RFC 10008 أن يتضمن مفتاح رد QUERY محتوى الطلب والبيانات الوصفية المناسبة. URI واحد مع جسمين مختلفين يعني سؤالين مختلفين. مفتاح مبني على الطريقة والعنوان وحدهما قد يعيد جواب مرشح إلى مرشح آخر.

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

يمكن لوسيط يفهم نوع الوسائط أن يطبّع فروقاً لا تغيّر المعنى. لكن التطبيع سلطة دلالية: حذف فراغات عُرّفت بأنها غير مهمة يختلف عن ترتيب قائمة يكون ترتيبها مهماً. المطابقة الإيجابية الخاطئة تعيد الجواب الخطأ قبل وصول الطلب إلى المنشأ. وno-transform توجيه داخل HTTP، لا إثبات تدقيق بأن أية طبقة لم تنتج صيغة معيارية للمفتاح.

يجب اختبار الاتجاهين: صيغ مختلفة للمعنى نفسه، ومعانٍ مختلفة تبدو متشابهة. الأرقام وUnicode والحقول المكررة والقيم الافتراضية وترميز المحتوى والتوقيعات وتقسيم الهوية كلها مهمة. عند غياب قاعدة مشتركة بين المحللات، الحفاظ على الاختلاف أقل خطراً من اختراع التكافؤ.

تسمية النتيجة تغيّر عمرها وسلطتها

يُشتق المورد المكافئ من المورد الهدف ومحتوى QUERY وبياناته الوصفية. يستطيع المنشأ تعيين URI له كي يسترجعه GET لاحقاً. تتحول عبارة مؤقتة إلى اسم يمكن نسخه وتخزينه ومشاركته.

لا يقول Location وContent-Location الشيء نفسه. في رد QUERY ناجح، قد يدل Location على مورد مكافئ أو مورد استعلام يمكن جلبه بواسطة GET. أما Content-Location فيربط التمثيل المعاد بعنوانه وفق دلالات HTTP. معاملتهما كعنوان canonical واحد يمحو ما قرر المنشأ أن يسميه.

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

يعرف RFC 3986 بنية المعرّف، لكنه لا يقرر سريته أو مدته. المنشأ الذي يسمي المورد يملك السلطة ويتحمل أثر الكشف والاستمرار.

رمز التحويل يحكم مصير الطريقة

تحافظ 301 و302 و307 و308 على QUERY؛ والاستثناء التاريخي الذي قد يحول POST إلى GET لا ينطبق. أما 303 فيطلب الانتقال صراحة إلى GET. وهكذا تعيد المجموعة الأولى إرسال الطريقة والمحتوى، بينما تشير الثانية إلى مورد.

إذا حوّل gateway الطريقة إلى GET بحكم العادة فقد يفقد المحتوى أو يعيده إلى URI. وإذا حوّلها إلى POST أزال الخاصية التي اعتمد عليها العميل في الإعادة. يجب اختبار كل رمز وتغيير origin وقواعد credential على حدة.

في QUERY الشرطية، تُفحص validators نسبة إلى التمثيل الذي كان GET سيختاره للمورد المكافئ. يظل تفاوض المحتوى والتفويض جزءاً من الاختيار. بصمة جسم السؤال ليست تلقائياً validator للجواب.

Accept-Query دليل محدود وحديث

يعلن Accept-Query أنواع الوسائط المقبولة بقائمة من RFC 9651. ينطبق الإعلان على المسار نفسه مع تجاهل query component في URI، وتُستخدم أحدث قيمة ما زالت fresh.

لا يثبت ذلك أن كل عبارة صحيحة أو أن كل عقدة توافق. يجب حفظ الرد الذي أصدر الحقل ومدة freshness والمسار وإصدار النشر.

وللمتصفح حد آخر. لا تعد QUERY من طرق CORS البسيطة في Fetch Standard، ولذلك يحتاج الاستخدام بين origin مختلفين إلى preflight. دعم التطبيق لا يكفي إذا رفض gateway أو WAF أو سياسة CORS الطريقة.

الخروج من URI لا يعني السرية

يمكن لـQUERY تقليل ظهور المرشحات في الروابط وسجلات URI، لكن المحتوى يمر عبر العميل وأدوات المتصفح وإنهاء TLS والبوابات والـcache وأنظمة التتبع والمنشأ. يمكن تسجيله وأخذ عينات منه وإرساله مرة أخرى. وقد ينقله redirect أو يعيد URI مكافئ سيئ التصميم كشفه.

يفيد تمييز Lu Heng بين السيطرة الرسمية والواقع العملي لسيادة البيانات: المنشأ يحدد الدلالة رسمياً، لكن الحيازة الفعلية موزعة على كل من يتلقى المحتوى أو بصمته.

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

أما أولوية الشيفرة العاملة فتحدد موقع الإثبات. يثبت RFC الوعد المشترك؛ وتثبت traces فقط أن المعالج كان آمناً، والإعادة متكررة الأثر، والمفتاح كاملاً، والاسم غير كاشف.