For sixteen years, developers who needed to ask complex questions of a server have been stuck with a workaround. When a

على مدار ستة عشر عاماً، ظل المطورون الذين يحتاجون إلى طرح أسئلة معقدة على الخادم عالقين في استخدام حلول مؤقتة. فعندما تكبر حمولة البحث (search payload) بحيث لا يمكن استيعابها في رابط URL، أو عندما ترفض المرشحات المتداخلة والمعلمات الحساسة الانضواء تحت سلسلة استعلام (query string)، كان الخيار العملي الوحيد هو استخدام POST. لقد نقل هذا النوع من الطلبات البيانات، لكنه كذب بشأن الغرض منها؛ إذ يشير POST إلى تغيير في الحالة. واستخدام هذه الطريقة لعملية مخصصة للقراءة فقط كان يجبر مسار الشبكة بالكامل — بما في ذلك ذاكرة التخزين المؤقت (caches)، والخوادم الوكيلة (proxies)، والمتصفحات — على التعامل مع عملية بحث بريئة كما لو أنها قد تغير قاعدة البيانات.

لقد انتهى هذا الحل الوسط أخيراً. ففي يونيو 2026، نشرت IETF وثيقة RFC 10008، التي وضعت معياراً رسمياً لطريقة QUERY. وهي أول طريقة HTTP جديدة منذ تقديم PATCH في عام 2010. وُجدت QUERY خصيصاً للطلبات الآمنة والمتماثلة (idempotent) التي تحتاج إلى جسم طلب (body). فهي لا تغير حالة الخادم، وتكرار الطلب نفسه يؤدي إلى نفس النتيجة. كما أنها قابلة للتخزين المؤقت (cacheable)، مما يعني أن الوسائط يمكنها تخزين الاستجابة وإعادة استخدامها. وعلى عكس GET، فهي تسمح بإرسال حمولة بيانات تماماً مثل POST.

وتعد استعلامات GraphQL ونقاط نهاية البحث المعقدة في REST من أكبر المستفيدين من هذا التغيير. فلن تضطر بعد الآن إلى حشر ستين معلمة استعلام في رابط URL واحد، أو إخفاء مستند مرشح JSON داخل جسم طلب POST ترفض الوسائط تخزينه مؤقتاً. لقد أصبحت الدلالات (semantics) الآن صادقة.

لكن وثيقة RFC ليست سوى حبر على ورق. فبين تطبيقك ومستخدميك توجد طبقة سميكة من البنية التحتية، ومعظمها لم يسمع بـ QUERY من قبل.

مشكلة التخزين المؤقت لم تُحل بعد

مع طلب GET، يكون التخزين المؤقت مباشراً؛ حيث يكون مفتاح التخزين المؤقت هو URI. ويحصل مستخدمان يطلبان نفس رابط URL على نفس الاستجابة المخزنة، بافتراض أن الرؤوس (headers) تسمح بذلك.

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

أولاً، يجب على خوادم الحافة (edge servers) وشبكات توصيل المحتوى (CDNs) تخزين جسم الطلب بالكامل قبل التمكن من حساب الهاش (hash). وهذا يتطلب ذاكرة ووقتاً عند عقدة الحافة. ثانياً، قد لا تنتج استعلامان متطابقان منطقياً نفس البايتات؛ فقد يرسل أحد العملاء {"status":"active"} بينما يرسل آخر {"status": "active"} مع اختلاف في المسافات البيضاء أو ترتيب المفاتيح. وما لم تقم طبقة التخزين المؤقت بتحليل الجسم وتوحيد صيغته (normalization and canonicalization) — عبر فرز مفاتيح JSON، وإزالة التنسيقات غير الضرورية، ومعالجة اختلافات الترميز — فإن نفس السؤال سيفشل في العثور على نتيجة في ذاكرة التخزين المؤقت في كل مرة.

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

من المحتمل أن تقوم أدواتك بحظرها أولاً

كل طلب HTTP يمر عبر مجموعة من الصناديق الوسيطة (middleboxes)، ومعظمها يفرض قواعد صارمة بشأن الطرق المسموح بها.

غالباً ما تعتمد جدران حماية تطبيقات الويب (WAF) وبوابات الـ API على قوائم سماح (allowlists) صريحة. وتسمح مجموعة القواعد النموذجية بـ GET وPOST وPUT وDELETE وPATCH، أما أي شيء آخر فيتم إسقاطه أو الرد عليه بـ 405 Method Not Allowed. ستصطدم QUERY بهذه الجدران قبل أن تصل إلى كود التطبيق الخاص بك.

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