سلسلة الاستعلام (query string) في الرابط هي أبسط صيغة لنقل البيانات: قائمة من أزواج key=value مفصولة بعلامة &. لكن هذه البساطة تتحول إلى مشكلة بمجرد الحاجة لنقل شيء أكثر تعقيدًا من قائمة نصية مسطحة.
لماذا سلسلة الاستعلام محدودة
صُممت صيغة سلسلة الاستعلام تاريخيًا لنماذج HTML البسيطة، ولا تحتوي على مفهوم مدمج لأنواع البيانات أو التداخل أو المصفوفات. كل شيء فيها نص، لذا فإن الرقم 42 والنص "42" لا يمكن تمييزهما إلا عندما يقوم كود ما بتحليلهما صراحةً.
ترميز المصفوفات: لا معيار موحّد
لا يوجد معيار واحد لترميز المصفوفات في سلسلة الاستعلام، وقد اعتمدت أطر العمل الخلفية المختلفة قواعد مختلفة: PHP يفهم بشكل أصلي tags[]=a&tags[]=b ويحوّلها تلقائيًا إلى مصفوفة، وكذلك filter[status]=active إلى بنية متداخلة — وهذا شائع جدًا في مواقع ووردبريس وأنظمة إدارة المحتوى المبنية بلغة PHP المنتشرة بكثرة في المنطقة العربية. بالمقابل، أطر عمل أخرى مثل ASP.NET تتوقع نفس المفتاح مكررًا دون أقواس: tags=a&tags=b. إذا اختلف العميل والخادم في القاعدة المتبعة، تُفقد بيانات المصفوفة أو تُشوَّه بصمت.
لماذا يحل JSON هذه المشكلة
يتضمن JSON أنواعًا مدمجة (أرقام، قيم منطقية، null) ودعمًا طبيعيًا للكائنات والمصفوفات المتداخلة دون الحاجة لأي اتفاقيات ترميز. لهذا السبب تُرسل البيانات المعقدة عادةً في جسم طلب POST بصيغة JSON، بينما تبقى سلسلة الاستعلام مخصصة للمعاملات البسيطة والمسطحة كالفلاتر أو رقم الصفحة.
لماذا يُستخدم هذا
- التحقق من الصيغة التي يتوقعها الخادم الخلفي لاستقبال معامل مصفوفة في سلسلة الاستعلام.
- تحويل معاملات الرابط إلى JSON لتسهيل التصحيح.
- فهم لماذا يُفضَّل عدم نقل بنية بيانات معقدة عبر معاملات GET.
حد طول الرابط
تفرض معظم المتصفحات والخوادم حدًا لطول الرابط يبلغ نحو 2000 حرف (القيمة الدقيقة تختلف حسب المتصفح والخادم)، لذا لا تصلح سلسلة الاستعلام فعليًا لنقل كميات كبيرة من البيانات. وهذا سبب إضافي يجعل طلبات POST بجسم JSON الخيار المعتاد للنماذج المعقدة أو بيانات المصفوفات، بينما يبقى GET مع سلسلة استعلام مخصصًا للمعاملات القصيرة والبسيطة.