طريقة HTTP QUERY: دليل المطور لمعيار RFC 10008 (2026)

في 15 يونيو 2026، نشرت هيئة IETF معيار RFC 10008 الذي يعرّف طريقة HTTP QUERY — أول طريقة HTTP جديدة منذ PATCH في عام 2010. ستة عشر عامًا مدة طويلة في عالم تطوير الويب، ولم تظهر QUERY فجأة: تعود الفكرة إلى مسودة عام 2015، ثم أُحييت في ورشة عمل HTTP عام 2019، واعتمدتها مجموعة عمل httpbis عام 2021 (تحت اسم SEARCH في البداية)، لتصل أخيرًا إلى النشر كمعيار رسمي هذا الصيف.

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

المشكلة: GET مقابل POST للاستعلامات المعقدة

لنأخذ مثالًا نموذجيًا للبحث عن المنتجات. النهج "الصحيح" وفق REST هو استخدام GET مع معاملات الاستعلام:

GET /products?category=shoes&maxPrice=100&sort=price_asc HTTP/1.1
Host: shop.example

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

لذلك يلجأ المطورون إلى POST:

POST /api/search HTTP/1.1
Content-Type: application/json
 
{ "category": "shoes", "maxPrice": 100, "sort": "price_asc" }

الأسلوب يعمل، لكن الدلالات خاطئة. إذ تخبر POST كل وسيط في الطريق — من ذاكرات التخزين المؤقت والخوادم الوكيلة إلى منطق إعادة المحاولة وأدوات المراقبة — بأن هذا الطلب قد يغيّر حالة النظام. وهذا يعني:

• لا تخزين مؤقت. استجابات POST غير قابلة عمليًا لإعادة الاستخدام من قبل الذاكرات المشتركة.
• لا إعادة محاولة آمنة. العميل الذي انقطع اتصاله لا يستطيع إعادة إرسال POST دون تفكير؛ فقد يكرر أثرًا جانبيًا. نقطة البحث لديك بلا آثار جانبية، لكن لا شيء في البروتوكول يصرّح بذلك.
• نية غامضة. تبدو الطلبات POST /search و POST /reports/run و POST /orders متطابقة على مستوى البروتوكول، رغم أن واحدًا منها فقط ينشئ شيئًا.

كل نقطة GraphQL، وكل استدعاء بحث في Elasticsearch، وكل واجهة تقارير برمجية، عاشت مع هذا التناقض لعقد كامل.

ما الذي تقدمه QUERY

يعرّف RFC 10008 طريقة QUERY بأنها تطلب من الخادم "معالجة المحتوى المرفق بطريقة آمنة وقابلة للتكرار ثم الاستجابة بنتيجة تلك المعالجة". ثلاث خصائص تميزها عن كل ما سبق:

طلب QUERY يشبه POST شكلًا لكنه يتصرف مثل GET. إليك المثال الرسمي من المعيار:

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json
 
select=surname,givenname,email&limit=10&match=%22email=*@example.*%22

HTTP/1.1 200 OK
Content-Type: application/json
 
[
  { "surname": "Smith", "givenname": "John", "email": "smith@example.org" },
  { "surname": "Jones", "givenname": "Sally", "email": "sally.jones@example.com" }
]

يمكن أن يكون الجسم بأي صيغة وسائط — ترميز النماذج، أو JSON، أو GraphQL، أو لغات استعلام مخصصة. ويعلن الخادم عما يقبله عبر ترويسة الاستجابة الجديدة Accept-Query التي تسرد أنواع الوسائط المدعومة بصياغة الحقول المهيكلة.

ولأن QUERY قابلة للتكرار، يمكن للعملاء والمكتبات إعادة محاولة طلب فشل بعد انقطاع الاتصال تلقائيًا — وهو ما يُمنع فعله مع POST. ولأنها آمنة، تستطيع أدوات المراقبة والأمان معاملتها كحركة قراءة فقط.

التخزين المؤقت: الجزء الأكثر إثارة

تُخزَّن استجابات GET وفق عنوان URL. أما استجابات QUERY فقابلة للتخزين أيضًا، لكن مفتاح التخزين يجب أن يتضمن محتوى الطلب وليس العنوان فقط. فطلبا QUERY إلى /search بجسمي JSON مختلفين هما مدخلان مختلفان في الذاكرة المؤقتة.

ويذهب المعيار أبعد من ذلك، إذ يسمح للذاكرات المؤقتة بتطبيع محتوى الطلب قبل حساب المفتاح — بتوحيد فروق ترميز المحتوى، أو المسافات وترتيب المفاتيح في JSON. إذا نُفّذ التطبيع جيدًا، يمكن لاستعلامين متكافئين بتنسيقين مختلفين إصابة نفس المدخل المخزّن. أما إذا نُفّذ بإهمال، فقد تؤدي أخطاء التطبيع إلى تقديم استجابة خاطئة لاستعلام آخر، وهو ما يصنفه المعيار صراحة ضمن الاعتبارات الأمنية.

تفصيلة أنيقة أخرى: يستطيع الخادم الرد على QUERY برمز 303 See Other موجهًا العميل إلى عنوان URI يمثل نتيجة الاستعلام. فيرسل العميل طلب GET عاديًا — محوّلًا استعلامًا مكلفًا يحمل جسمًا إلى مورد قابل للمشاركة والتخزين المؤقت التقليدي.

دعم أطر العمل والمنظومة في 2026

الاعتماد مبكر لكنه حقيقي:

• ‎.NET 10 يقدم دعمًا كاملًا في الجانبين. يوفر العميل HttpMethod.Query، ويوفر ASP.NET Core 10 الثابت HttpMethods.Query مع الدالة HttpMethods.IsQuery():

// العميل
using var request = new HttpRequestMessage(HttpMethod.Query, "https://api.example/products/search")
{
    Content = JsonContent.Create(filter)
};
 
// الخادم (ASP.NET Core 10)
app.MapMethods("/products/search", new[] { HttpMethods.Query }, async (HttpRequest req) =>
{
    var filter = await req.ReadFromJsonAsync<ProductFilter>();
    return Results.Ok(await search.RunAsync(filter));
});

أما المساعدات المختصرة مثل MapQuery() وسمة [HttpQuery] فقد حُذفت من هذا الإصدار، لذا تكتب الفرق امتدادات مغلّفة صغيرة حاليًا.

• Node.js وغيرها: بما أن QUERY مجرد رمز طريقة إضافي نحويًا، تمرره معظم خوادم HTTP؛ ويصل الدعم على مستوى الموجّهات تدريجيًا عبر أطر العمل.
• المتصفحات: لا تستطيع fetch ولا XHR إرسال QUERY بعد، وليست QUERY ضمن القائمة الآمنة لطرق CORS، لذا يستلزم الاستخدام عبر النطاقات طلب فحص مسبق دائمًا. حاليًا، تتألق QUERY في التواصل بين الخوادم.
• شبكات CDN والخوادم الوكيلة: رغم مشاركة مهندسين من Cloudflare و Akamai في تأليف المعيار، فإن التخزين المؤقت لاستجابات QUERY على نطاق واسع عند الحافة ليس موثوقًا بعد.
• OpenAPI: لا توفر النسخة 3.1 وسيلة لوصف نقاط QUERY؛ ويستبعدها ASP.NET Core ببساطة من المستندات المولّدة.

هل تعتمد QUERY الآن؟

قائمة عملية للقرار:

اعتمدها الآن إذا كنت تتحكم في العميل والخادم معًا — الخدمات المصغرة الداخلية، وطبقات الواجهة الخلفية للواجهة الأمامية، وواجهات البيانات خلف بوابتك الخاصة. ستحصل مجانًا على دلالات صادقة، وإعادة محاولات تلقائية آمنة، وتخزين مؤقت متوافق مع المستقبل.

انتظر إذا كان مستهلكوك متصفحات، أو جهات خارجية تعتمد على حزم SDK مولّدة من OpenAPI، أو إذا كنت تعتمد اليوم على التخزين المؤقت لنتائج الاستعلام عند الحافة.

نصيحة تصميمية: وفّر QUERY إلى جانب POST احتياطية على نفس المسار خلال المرحلة الانتقالية، وأعلن الدعم عبر Accept-Query. العملاء الذين يفهمون QUERY يحصلون على الدلالات الأفضل؛ والقدامى لا يخسرون شيئًا.

في نقطة، نرى أن QUERY ملائمة تمامًا لنقاط البحث والتقارير في معماريات API-first التي نبنيها — خاصة في خطوط عمل وكلاء الذكاء الاصطناعي، حيث يستفيد الوكلاء الذين يستدعون الأدوات عبر HTTP استفادة كبيرة من طلبات معلنة الأمان وقابلية إعادة المحاولة على مستوى البروتوكول.

الخلاصة

تسد QUERY فجوة قائمة منذ HTTP/1.1: لم تعد طلبات القراءة ذات الحمولات الحقيقية بحاجة إلى التنكر في هيئة عمليات كتابة. الطريقة أصبحت معيارًا رسميًا، و ‎.NET 10 يشحنها بالفعل، وبقية المنظومة تلحق بالركب. لست بحاجة إلى إعادة كتابة واجهاتك البرمجية غدًا — لكن في المرة القادمة التي تصمم فيها نقطة بحث وتشعر بذلك الانزعاج المألوف من POST /search، اعلم أن البروتوكول يملك أخيرًا إجابة أفضل.

ستة عشر عامًا بين طريقتين جديدتين توحي بأن هذه كانت تستحق الانتظار.