كيف روّج دوغلاس كروكفورد لـ JSON ولماذا أصبح التنسيق الافتراضي لتطبيقات الويب وواجهات برمجة التطبيقات — مع نصائح عملية لاستخدام JSON بشكل جيد اليوم.

JSON (JavaScript Object Notation) هو طريقة خفيفة لتمثيل البيانات كنص عادي باستخدام أزواج مفتاح–قيمة وقوائم.
إذا كنت تبني تطبيقات ويب — حتى لو لم تفكر كثيراً في "تنسيقات البيانات" — فـ JSON على الأرجح هو الرابط الذي يجمع منتجك. إنه كيف يطلب الواجهة الأمامية البيانات، وكيف يرد الخادم، وكيف تزامن تطبيقات الهاتف الحالة، وكيف ترسل الخدمات الخارجية الأحداث. عندما يكون JSON واضحاً ومتناسقاً، تطلق الفرق الميزات أسرع؛ عندما يكون فوضوياً، يستغرق كل ميزة وقتاً أطول لأن الجميع يتجادل حول ما الذي "تعنيه" البيانات.
إليك كائن JSON صغير يمكنك قراءته من لمحة:
{
"userId": 42,
"name": "Sam",
"isPro": true,
"tags": ["beta", "newsletter"]
}
حتى بدون سياق تقني، عادة يمكنك استنتاج ما يجري: مستخدم له معرف، واسم، وعلم حالة، وقائمة علامات.
سوف تتعلم:
الهدف بسيط: مساعدتك على فهم ليس فقط ما هو JSON، بل لماذا "تتحدث" به تقريباً كل تطبيق—وكيف تتجنب الأخطاء الشائعة التي تكررها الفرق.
دوغلاس كروكفورد لم "يخترع" كل فكرة وراء JSON، لكنه فعل شيئاً بنفس القدر من الأهمية: جعل نمطاً بسيطاً وعملياً مرئياً، سماه، ودفعه إلى التيار الرئيسي.
في أيام الويب المبكرة، كانت الفرق تتعامل مع خيارات محرجة لنقل البيانات بين المتصفح والخادم. كان XML شائعاً لكنه مطوّل. كانت الصيغ المخصصة المعتمدة على محددات مضغوطة لكنها هشة. كان بالإمكان أن يقيم جافاسكربت البيانات ككود، لكن ذلك طمس الفاصل بين "البيانات" و"النص القابل للتنفيذ"، وكان ذلك وصفة للأخطاء ومشكلات الأمان.
رأى كروكفورد مساراً أنظف: استخدم مجموعة فرعية صغيرة من تراكيب قيم جافاسكربت الحرفية التي يمكنها تمثيل البيانات العادية بشكل موثوق — كائنات، مصفوفات، سلاسل، أرقام، بوليان، وnull — بدون ميزات إضافية.
أحد أكبر مساهمات كروكفورد كانت اجتماعية أكثر منها تقنية: سمّاها JSON (JavaScript Object Notation) ونشر توثيقاً واضحاً في json.org. هذا أعطى الفرق مفردات مشتركة ("سنرسل JSON") ومرجعاً موجزاً يكفي للقراءة والتنفيذ.
كما روج كروكفورد لـ JSON كتنسيق بيانات مستقل عن جافاسكربت كلغة برمجة: يمكن للغات عديدة تفكيكها وتوليدها، وكانت تتطابق طبيعياً مع هياكل البيانات الشائعة.
يتسارع الاعتماد عندما تشعر الفرق بأن من الآمن المراهنة على تنسيق طويل الأجل. نال JSON ذلك النوع من الثقة تدريجياً عبر معالم معيارية معروفة:
ساهمت حملات كروكفورد، مجتمعة مع هذه المعايير ونمو مكتبات التحليل، في تحوّل JSON من عرف مفيد إلى الطريقة الافتراضية لتواصل التطبيقات — خصوصاً عبر واجهات HTTP (مغطاة لاحقاً في /blog/json-and-apis).
قبل أن يصبح JSON الطريقة الافتراضية لتحريك البيانات، اعتمد الويب على مزيج من التنسيقات التي كانت إما ثقيلة جداً، أو غير متسقة، أو مخصصة للغاية بحيث لا يمكنها التوسع عبر الفرق.
كان XML الخيار "القياسي" الأكبر. كان يعمل عبر اللغات، وكان هناك أدوات له، ويمكنه تمثيل بنى متداخلة. لكنه جلب الكثير من الطقوس معه.
في الوقت نفسه، كانت العديد من التطبيقات تمرر البيانات كسلاسل استعلام مخصصة (خاصة في طلبات أسلوب AJAX المبكرة): أزواج مفتاح/قيمة محشورة في عناوين URL أو أجسام POST. اخترع آخرون صيغ نصية عشوائية—قوائم مفصولة بفواصل هنا، وكتل مفصولة بأنابيب هناك—غالباً مع قواعد هروب مطبوخة يدوياً لا يفهمها سوى مطور واحد.
المشكلات الشائعة لم تكن نظرية:
معظم التطبيقات لا تحتاج تنسيقاً يمكنه التعبير عن كل بنية مستند ممكنة. تحتاج طريقة متوقعة لإرسال الكائنات والمصفوفات والسلاسل والأرقام والقيم البولينية — بسرعة، وبشكل متسق، ومع أقل مجال للتأويل. تقلل الصيغ الأبسط عدد القرارات (والأخطاء) التي تتخذها الفرق لكل نقطة نهاية.
<user>
<id>42</id>
<name>Ada</name>
<isActive>true</isActive>
</user>
{
"id": 42,
"name": "Ada",
"isActive": true
}
كلاهما يعبر عن نفس الفكرة، لكن JSON أسهل في المسح، وأسهل في التوليد، وأقرب إلى كيفية نمذجة معظم التطبيقات للبيانات في الذاكرة.
ثبات JSON ليس حادثاً. ينجح لأنه صغير بشكل متعمد: فقط هيكل كافٍ لتمثيل بيانات التطبيقات الحقيقية دون دعوة التنوع اللامتناهي.
يمنحك JSON مجموعة أدوات بسيطة تتطابق بسلاسة مع كيفية تفكير معظم التطبيقات في البيانات:
name، email)true/falseهذا كل شيء. لا تواريخ، لا تعليقات، لا أنواع رقمية مخصصة، لا مراجع. تبسط هذه البساطة تنفيذ JSON عبر اللغات والمنصات.
JSON قابل للقراءة بما يكفي ليقرأه الناس سريعاً في السجلات واستجابات API، وفي نفس الوقت سهل على الآلات تحليله بسرعة. يتجنب الطقوس الزائدة، لكنه يحتفظ بفواصل واضحة ({}, [], :) حتى تكون المحللات سريعة وموثوقة.
المقايضة: لأن JSON مُصغَّر جداً، يجب على الفرق الاتفاق على اعراف لأشياء مثل الطوابع الزمنية، والعملات، والمعرفات (مثلاً سلاسل ISO-8601 للتواريخ).
قواعد JSON الصارمة (سلاسل بين علامتي اقتباس مزدوجتين، لا فواصل معلقة، مجموعة أنواع ثابتة صغيرة) تقلل الغموض. غموض أقل يعني أخطاء "يعمل على جهازي" أقل عندما تتبادل الأنظمة البيانات.
يشبه شكل JSON بناء جملة كائنات جافاسكربت، لكن JSON ليست جافاسكربت. إنها تنسيق بيانات مستقل عن اللغة بقواعده الخاصة، قابلة للاستخدام من بايثون، جافا، غو، روبي، وأي مكان آخر يحتاج إلى تسلسل متسق وقابل للتشغيل البيني.
انتصار JSON لم يكن لأنه الأكثر غنى بالميزات. فاز لأنه يناسب طريقة بناء تطبيقات الويب بالفعل: متصفح ثقيل بجافاسكربت يتحدث إلى خادم عبر طلبات HTTP بسيطة.
بمجرد أن اعتمدت المتصفحات جافاسكربت، كان لدى الجانب العميل وسيلة مدمجة لتمثيل البيانات المهيكلة: كائنات، مصفوفات، سلاسل، أرقام، بوليات، وnull. طابق JSON هذه البدائيات عن كثب، لذا كان نقل البيانات بين "ما يفهمه المتصفح" و"ما يرسله الخادم" طبيعياً.
سرّعت تطبيقات أسلوب Ajax المبكرة هذا. بدلاً من إرجاع صفحات HTML كاملة، كان بإمكان الخوادم إرجاع حمولة صغيرة ليعرضها الواجهة. استجابة كهذه كانت مفيدة مباشرة:
{
"user": {"id": 42, "name": "Sam"},
"unreadCount": 3
}
حتى لو بدا بناء JSON مثل جافاسكربت، فهو محايد للغة. بمجرد أن احتاج الخوادم والعملاء بلغات أخرى للتشغيل البيني مع واجهات الويب، ظهرت مكتبات JSON — وسرعان ما أصبحت "معدات قياسية". تحويل سلسلة JSON إلى هياكل بيانات محلية عادة ما يكون استدعاء دالة واحدة، وتوليد JSON بسيط بالمثل.
بمجرد أن افترضت الأطر، عملاء API، المصححات، البروكسيات، وأدوات التوثيق JSON، خلق اختيار شيء آخر احتكاكاً. كان بإمكان المطورين فحص الحمولات في أدوات المطور في المتصفح، نسخ/لصق الأمثلة في الاختبارات، والاعتماد على مكتبات ناضجة للترميز، فك الترميز، ومعالجة الأخطاء.
يمكن أن تخدم استجابة JSON واحدة واجهة ويب، تطبيق محمول، خدمة داخلية، وتكامل طرف ثالث مع تغييرات طفيفة. جعلت هذه التشغيلية JSON رهاناً آمناً للفرق التي تبني "خادم واحد، واجهات متعددة" — وساعدت في أن تصبح العقدة الافتراضية بين العميل والخادم.
لم يفز JSON لأنه فخم — بل لأنه ملائم لآلية عمل الويب. HTTP مبني حول إرسال طلب والحصول على استجابة، وJSON طريقة سهلة ومتوقعة لتمثيل "جسم" تلك الاستجابة (أو الطلب) كبيانات مهيكلة.
عادة يتضمن طلب API طريقة وعنوان URL (مثلاً GET /users?limit=20). يرد الخادم برمز حالة (مثل 200 أو 404)، رؤوس، وجسم اختياري.
عندما يكون الجسم JSON، رأس مهم هو:
Content-Type: application/jsonيخبر هذا الرأس العملاء بكيفية تفسير البايتات التي يتلقونها. في الطريق الداخل (العميل → الخادم)، إرسال Content-Type: application/json يشير إلى "أنا أرسل JSON"، ويمكن للخوادم تحليله بشكل متسق.
يعمل JSON جيداً خاصة لأنماط تتكرر عبر العديد من واجهات برمجة التطبيقات.
الترقيم (pagination) غالباً ما يلف قائمة ببيانات وصفية:
{
"data": [{"id": 1, "name": "A"}],
"pagination": {"limit": 20, "offset": 0, "total": 153}
}
الترشيح والفرز يحدثان عادة في سلسلة الاستعلام بالعنوان، بينما تبقى النتائج كمصفوفة JSON (أو حقل data). على سبيل المثال: GET /orders?status=paid&sort=-created_at.
استجابات الخطأ تستفيد من شكل موحد حتى يتمكن العملاء من عرض رسائل والتعامل مع إعادة المحاولة:
{
"error": {
"code": "invalid_request",
"message": "limit must be between 1 and 100",
"details": {"field": "limit"}
}
}
الملاءمة العملية بسيطة: HTTP يوفر النقل والمعنى (أفعال، رموز حالة، التخزين المؤقت)، بينما يوفر JSON بنية خفيفة وقابلة للقراءة للبيانات نفسها.
عندما يقارن الناس JSON وXML، فهم غالباً يقارنون "البيانات للتطبيقات" مقابل "الوثائق". كلا التنسيقين يمكنهما تمثيل معلومات مهيكلة، لكن JSON يميل إلى مطابقة ما تحركه معظم التطبيقات بالفعل: كائنات بسيطة، قوائم، سلاسل، أرقام، بوليات، وnull.
XML مطوّل بالتصميم. تكرار العلامات الافتتاحية والإغلاق يجعل الحمولات أكبر وأصعب للمسح في السجلات أو أدوات تفتيش الشبكة. عادة ينقل JSON نفس المعنى بأحرف أقل وضوضاء بصرية أقل، مما يساعد أثناء تصحيح الأخطاء ويمكن أن يقلل تكاليف النطاق الترددي على نطاق.
هذا ليس مجرد شكل: الحمولات الأصغر غالباً ما تعني نقل أسرع وعمل أقل للمحللات والمرررات.
تبدو بيانات معظم التطبيقات طبيعياً كقواميس (خرائط مفتاح/قيمة) ومصفوفات (قوائم): مستخدم بسماته، طلب بعناصره، صفحة بمكوناتها. يتطابق JSON مباشرة مع هذا النموذج الذهني، ويتطابق مع هياكل البيانات المحلية في جافاسكربت ومعظم اللغات الحديثة.
يمكن لـ XML تمثيل نفس الهياكل، لكنه عادة يتطلب اعرافاً: سمات مقابل عناصر، عناصر طفل مكررة للقوائم، وقواعد إضافية لـ "ما الذي يُحتسب كرقم" (لأن كل شيء نص ما لم تضف نوعية فوق ذلك).
يظل XML قوياً لحالات الاستخدام المركزة على المستندات: المحتوى المختلط (نص متداخل بعلامات)، سلاسل نشر، ونظم بيئية بها أدوات XML ناضجة (مثل بعض التكاملات المؤسسية). إذا كانت الحمولات أقرب إلى مستند منها إلى رسم كائن، فقد يكون XML مناسباً.
إذا كان هدفك الأساسي تبادل بيانات التطبيق بين الواجهة الأمامية، والخلفية، وواجهات برمجة التطبيقات، فإن JSON عادة اختيار أبسط وأكثر مباشرة. إذا كنت بحاجة إلى تمييز الوثائق، محتوى مختلط، أو التكامل في نطاق ثقيل على XML، فربما يكون XML هو الأداة المناسبة.
يشبه JSON "كائنات جافاسكربت"، لذا تفترض الفرق غالباً أنه يمكنها معاملته كجافاسكربت. هنا تتسلل الأخطاء: JSON أكثر صرامة، أصغر، وأقل تسامحاً.
بعض قضايا "يعمل على جهازي" تظهر مراراً وتكراراً:
{name: "Ada"} ليس JSON؛ { "name": "Ada" } هو.{ "a": 1, } سيفشل في العديد من المحللات.// و/* ... */ غير صالحين. إذا احتجت ملاحظات، احتفظ بها في التوثيق أو استخدم حقلاً منفصلاً (بحذر) أثناء التطوير.هذه القيود مقصودة: تبقي المحللات بسيطة ومتسقة عبر اللغات.
JSON له نوع رقمي واحد: number. لا يوجد نوع صحيح مدمج، أو عشري، أو تاريخ.
"19.99") لتجنب اختلافات التقريب عبر الأنظمة."2025-12-26T10:15:30Z"). تجنب صيغ تواريخ مخصصة تتطلب تخميناً.JSON يدعم Unicode، لكن الأنظمة الحقيقية لا تزال تتعثر حول الترميز والتهرب:
" والشرطة المائلة العكسية \\).دوماً حلل JSON باستخدام محلل JSON حقيقي (JSON.parse أو ما يعادله في لغتك). تجنب أي نهج على طريقة eval، حتى لو بدا "أسرع". وقم بالتحقق من المدخلات عند الحواف — خصوصاً في واجهات برمجة التطبيقات العامة — حتى لا تتسرب حقول أو أنواع غير متوقعة إلى المنطق التجاري.
حمولة JSON ليست مجرد "بيانات أثناء النقل" — إنها واجهة طويلة الأمد بين الفرق، والأنظمة، والمستقبل أنت. الفرق بين حمولة تدوم وواحدة تعاد كتابتها كل ربع سنة هو عادة انضباط ممل: اتساق، إدارة تغييرات حذرة، وحالات حافة متوقعة.
اختر قواعد التسمية والتزم بها في كل مكان:
camelCase أو snake_case) ولا تخلط.userId إلى id تغيير كاسر حتى لو بدا المعنى "واضحاً"."count": 3 مقابل "count": "3") سيسبب أخطاء يصعب تتبعها.يمكنك تجنب معظم حروب الإصدارات بجعل التغييرات إضافية:
/v2/...) أو تضمين إشارة إصدار واضحة في رأس—لا تغير الدلالة بصمت.يتعامل العملاء مع الفشل بشكل أفضل عندما تتشارك الأخطاء شكل واحد:
{
"error": {
"code": "INVALID_ARGUMENT",
"message": "email must be a valid address",
"details": { "field": "email" }
}
}
التوثيق الجيد يتضمن أمثلة حقيقية — استجابات ناجحة وفاشلة — مع الحقول الكاملة. حافظ على تزامن الأمثلة مع سلوك الإنتاج، واشرح الحقول الاختيارية، القابلة لأن تكون null، أو المتقادمة. عندما تتطابق الأمثلة مع الاستجابات الحقيقية، تكون عمليات التكامل أسرع وتتعطل أقل.
إذا كنت تستخدم سير عمل vibe-coding لتدوير ميزات جديدة بسرعة، تصبح عقود JSON أكثر أهمية: التكرار السريع رائع حتى تبدأ عملاء وخدمات في الانحراف.
على Koder.ai، تولد الفرق عادة واجهة React أمامية بالإضافة إلى خلفية Go + PostgreSQL ثم تتكرر على أشكال API في وضع التخطيط قبل تثبيتها. تساعد ميزات مثل اللقطات والعودة عندما يتبين أن تغيير JSON "صغير" كان كاسراً، وتصدير شفرة المصدر يجعل من السهل الاحتفاظ بالعقدة في المستودع وفرضها بالاختبارات.
JSON سهل التوليد، وهذا قوة وكمين في آن معاً. إذا أرسل خادم ما "age": "27" (سلسلة) وآخر يتوقع 27 (رقم)، لا شيء في JSON نفسه سيوقف ذلك. عادة ما تكون النتيجة أسوأ نوع من الأخطاء: تعطل عميل في الإنتاج، أو خلل واجهة دقيق يحدث فقط مع بعض البيانات.
التحقق يكتشف البيانات السيئة أو غير المتوقعة قبل أن تصل إلى الجهات التي تعتمد عليها — الواجهة الأمامية، تكامل الشركاء، خط أنابيب التحليلات، أو تطبيقات الهاتف. نقاط الفشل الشائعة تشمل الحقول المطلوبة المفقودة، المفاتيح المعاد تسميتها، الأنواع الخاطئة، والقيم "قريبة من الصحيحة" (مثل تواريخ بصيغ غير متسقة). خطوة تحقق صغيرة عند حدود API يمكن أن تحول هذه المشاكل من انقطاعات إلى رسائل خطأ واضحة.
مخطط JSON هو طريقة معيارية لوصف شكل JSON: الخصائص المطلوبة، الأنواع المسموح بها، القيم المعدودة، الأنماط، والمزيد. يكون مفيداً خصوصاً عندما:
مع مخطط، يمكنك التحقق من الطلبات على الخادم، والتحقق من الاستجابات في الاختبارات، وتوليد التوثيق. الكثير من الفرق تربطه مع وثائق API (غالباً عبر OpenAPI)، بحيث تصبح العقدة صريحة بدلاً من "معرفة قبلية". إذا كنت تنشر وثائق للمطورين بالفعل، ربط أمثلة المخطط من /docs يمكن أن يُبقي الأمور متسقة.
ليس كل فريق بحاجة إلى أدوات مخطط كاملة من اليوم الأول. خيارات عملية تشمل:
قاعدة مفيدة: ابدأ بالأمثلة واختبارات العقدة، ثم أضف مخطط JSON عندما تبدأ التغييرات والتكاملات بالتكاثر.
يبدو JSON "خفيفاً" عندما ترسل بضعة حقول. على نطاق واسع — عملاء محمولون على شبكات ضعيفة، واجهات API عالية الحركة، صفحات كثيفة تحليلات — يمكن أن يصبح JSON مشكلة أداء أو مخاطرة موثوقية إذا لم تشكّل وترسله بعناية.
أكثر مشكلة مقياسية شائعة ليست تحليل JSON — إنها إرسال الكثير منه.
الترقيم هو الفوز البسيط: أعد قطعاً متوقعة (مثلاً limit + cursor) حتى لا ينزل العملاء آلاف السجلات دفعة واحدة. للنقاط النهاية التي ترجع كائنات متداخلة، فكّر في الاستجابات الجزئية: دع العميل يطلب فقط ما يحتاجه (حقول مختارة أو توسعات "include"). هذا يمنع "الإفراط في الجلب"، حيث تحتاج شاشة ما فقط name وstatus لكنها تتلقى كل التفاصيل التاريخية وحقول التكوين.
قاعدة عملية: صمم الاستجابات حول إجراءات المستخدم (ما تحتاجه الشاشة الآن)، لا حول ما يمكن لقاعدة البيانات الربط به.
إذا خدمت API الخاص بك استجابات JSON كبيرة، يمكن للضغط أن يقلص حجم النقل دراماتيكياً. يمكن للعديد من الخوادم gzip أو brotli الاستجابات تلقائياً، ومعظم العملاء يتعاملون معها دون كود إضافي.
الذاكرة المؤقتة (caching) هي رافعة أخرى. على مستوى عالٍ، استهدف:
هذا يقلل التنزيلات المتكررة ويُنعّم ذروة الحركة.
للمخرجات الكبيرة جداً — تصديرات، خلاصات أحداث، مزامنة جماعية — فكّر في استجابات متدفقة أو تحليل تدريجي حتى لا يضطر العملاء إلى تحميل مستند كامل في الذاكرة قبل أن يفعلوا أي شيء مفيد. ليس مطلوباً لمعظم التطبيقات، لكنه خيار ثمين عندما يبدأ "مخزون JSON واحد كبير" في التسبب في انتهاء مهلة الطلبات.
JSON سهل التسجيل، وهذا مفيد وخطير في آن واحد. تعامل مع السجلات كواجهة منتج:
عند التنفيذ الجيد، ستُصَحِّح أسرع مع تقليل خطر كشف البيانات عن طريق الخطأ.
JSON ليس "منتهياً" — إنه مستقر. ما يتغير الآن هو النظام البيئي حوله: محررات أقوى، تحقق أفضل، عقود API أكثر أماناً، وأدوات تساعد الفرق على تفادي التغييرات الكاسرة عن غير قصد.
من المرجح أن يبقى JSON التنسيق الوسيطي الافتراضي لمعظم تطبيقات الويب والمحمول لأنه مدعوم على نطاق واسع، وسهل تصحيحه، ويتطابق بوضوح مع هياكل البيانات الشائعة.
أكبر تحول هو نحو واجهات API ذات أنماط ثابتة: الفرق ما زالت ترسل JSON، لكنها تعرفه بدقة أكبر باستخدام أدوات مثل JSON Schema، OpenAPI، ومولِّدات الشفرة. هذا يعني لحظات أقل "خمن شكل البيانات"، إكمال أوتوماتيكي أفضل، واكتشاف أخطاء أبكر — دون التخلي عن JSON ذاته.
عندما تحتاج إلى إرسال أو تخزين سجلات كثيرة بكفاءة (سجلات، أحداث تحليلات، تصديرات)، قد تكون مصفوفة JSON العملاقة محرجاً. JSON Lines (المعروف أيضاً باسم NDJSON) يحل ذلك بوضع كائن JSON واحد في كل سطر. يتدفق جيداً، يمكن معالجته سطراً بسطر، ويتعامل جيداً مع أدوات سطر الأوامر.
استخدم هذا كفحص ما قبل الإقلاع للحمولات التي ستعيش أكثر من سبرينت:
2025-12-26T10:15:00Z).null ودوّن اختيارك.إذا أردت التعمق، تصفح الأدلة المتعلقة على /blog — خصوصاً مواضيع مثل التحقق بالمخطط، إصدار API، وتصميم الحمولات للتوافق طويل الأمد.