مقال مكتوب في سبتمبر 2017
تولى JSON السيطرة على العالم. إذا كان هناك تطبيقان يتواصلان مع بعضهما البعض عبر الإنترنت اليوم ، فمن المرجح أن يفعلوا ذلك باستخدام JSON. يتم قبول المعيار من قبل جميع اللاعبين الرئيسيين: من بين عشرة واجهات برمجة تطبيقات الويب الأكثر شيوعًا ، والتي تم تطويرها بشكل أساسي من قبل الشركات الكبيرة مثل Google و Facebook و Twitter ،
هناك واجهة برمجة تطبيقات واحدة فقط تنقل البيانات بتنسيق XML ، وليس JSON. على سبيل المثال ، دعم Twitter XML حتى عام 2013 ، عندما أصدر إصدارًا جديدًا من واجهة برمجة التطبيقات حصريًا في JSON. من بين المطورين الآخرين ، تحظى JSON بشعبية كبيرة أيضًا: وفقًا لـ Stack Overflow ،
يتم طرح أسئلة حول JSON أكثر من أي تنسيق آخر لتبادل البيانات .
XML لا يزال على قيد الحياة ويستخدم كثيرًا. على سبيل المثال ، بتنسيقات الويب SVG و RSS و Atom. إذا كان مؤلف تطبيق Android يريد أن يعلن أنه يحتاج إلى إذن من المستخدم ، فهو يفعل ذلك في بيان التطبيق المكتوب بلغة XML. و XML ليس بديل JSON الوحيد: يختار بعض المطورين YAML أو Protocol Buffers من Google. لكن هذه التنسيقات بعيدة عن كونها شائعة مثل JSON ، والتي أصبحت الآن المعيار الفعلي لتبادل البيانات بين البرامج عبر الإنترنت.
إن هيمنة JSON مذهلة ، حيث كان الجميع في عام 2005 يناقشون إمكانات "JavaScript و XML غير المتزامنة" بدلاً من "JavaScript و JSON غير المتزامنين". بالطبع ، هناك احتمال أن هذا لا يقول أي شيء عن الشعبية النسبية للصيغتين ، فقط يبدو أن AJAX هو اختصار أكثر جاذبية من AJAJ. ولكن على الرغم من أن بعض الأشخاص استخدموا JSON بالفعل بدلاً من XML في عام 2005 ، إلا أنك لا تزال تتساءل عن كيفية انخفاض XML بشكل حاد لدرجة أنه بعد عقد من الزمن ، فإن عبارة "JavaScript و XML غير المتزامنة" تسبب ابتسامة ساخرة. ماذا حدث خلال هذا العقد؟ كيف استبدل JSON XML في العديد من التطبيقات؟ ومن الذي اخترع تنسيق البيانات هذا ، والذي يعتمد عليه المهندسون والأنظمة في جميع أنحاء العالم الآن؟
ولادة JSON
تم إرسال أول رسالة JSON في أبريل 2001 من جهاز كمبيوتر في مرآب بالقرب من سان فرانسيسكو. احتفظ التاريخ بأسماء المتورطين في الحدث: دوجلاس كروكفورد وتشيب مورنينغستار ، مؤسسا شركة الاستشارات التكنولوجية ستيت سوفتوير.
كان هذان التطبيقان يعملان على تطوير تطبيقات AJAX قبل وقت طويل من ظهور مصطلح AJAX. لكن دعم التطبيق في المتصفحات لم يكن جيدًا جدًا. لقد أرادوا نقل البيانات إلى تطبيقهم بعد التحميل الأولي للصفحة ، لكنهم لم يجدوا طريقة تعمل في جميع المتصفحات.
من الصعب تصديق ذلك اليوم ، لكن Internet Explorer كان المتصفح الأكثر تقدمًا في عام 2001. منذ عام 1999 ، يدعم Internet Explorer 5 الشكل المبكر لـ XMLHttpRequest من خلال ActiveX. يمكن لـ Crockford و Morningstar استخدام هذه التقنية لاسترداد البيانات في التطبيق ، لكنها لم تعمل في Netscape 4. وبالتالي ، كان علي البحث عن تنسيق مختلف يعمل في كلا المستعرضين.
ظهرت رسالة JSON الأولى على النحو التالي:
<html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session", do: "test", text: "Hello world" } ) </script></head></html>
فقط جزء صغير من الرسالة يشبه JSON كما نعرفه اليوم. الرسالة نفسها هي في الواقع مستند HTML مع سطرين من JavaScript. الجزء الشبيه بـ JSON هو مجرد حرف حرفي لجافا سكريبت للدالةلقي
receive() .
قرر كروكفورد ومورنينجستار إساءة استخدام إطار HTML لإرسال البيانات. بالنسبة للإطار ، يمكنك تحديد عنوان URL يعرض مستند HTML مشابهًا لما ورد أعلاه. عندما يتم استلام HTML ، يتم تشغيل JavaScript ويمرر الحرف الحر إلى التطبيق. نجح هذا الأمر بشرط التحايل على حماية المتصفح بعناية لمنع الطفل من الوصول إلى النافذة الرئيسية: كما ترى ، قام كل من Crockford و Morningstar بتعيين نطاق المستند بشكل صريح. تسمى هذه التقنية أحيانًا بإطار مخفي ؛
غالبًا ما كانت
تُستخدم في أواخر التسعينات قبل XMLHttpRequest العادي .
ما يثير الدهشة في أول مشاركة JSON هو أنه ليس من الواضح على الإطلاق أن هذا هو الاستخدام الأول لنوع جديد من تنسيق البيانات. انها مجرد جافا سكريبت! في الواقع ، فكرة استخدام جافا سكريبت بهذه الطريقة بسيطة لدرجة أن كروكفورد نفسه يعتقد أنه لم يكن أول من يفعل ذلك - يدعي أن شخصًا في نيتسكيب استخدم مجموعة صفيفات جافا سكريبت لنقل المعلومات
مرة أخرى في عام 1996 . لا يتطلب النشر في جافا سكريبت عادي أي تحليل خاص. كل شيء يقوم به مترجم جافا سكريبت.
في الواقع ، واجهت رسالة JSON الأولى في التاريخ مشاكل مع المترجم. تحتفظ جافا سكريبت بعدد كبير من الكلمات - تم حجز 64 كلمة في ECMAScript 6 - واستخدمها كروكفورد ومورنينجستار دون قصد في رسالتهم: أي أن الكلمة المحجوزة تعمل كمفتاح. نظرًا لأن جافا سكريبت بها العديد من الكلمات المحجوزة ، فقد قرر كروكفورد عدم تجنبها ، ولكن ببساطة اقتبس كل مفاتيح JSON. يعتبر مترجم JavaScript المفتاح المقتبس كسلسلة ، لذا يمكنك استخدام الكلمات المحجوزة بأمان. هذا هو السبب في أن مفاتيح JSON لا تزال مقتبسة.
أدرك كروكفورد ومورنينجستار أن الطريقة الجديدة يمكن استخدامها في جميع أنواع التطبيقات. أرادوا استدعاء تنسيق JSML (لغة ترميز جافا سكريبت) ، ولكن اتضح أن الاختصار مشغول بالفعل بشيء يسمى لغة ترميز لغة جافا. لذلك ، اخترنا Javascript Object Notation ، أي JSON. بدأوا في تقديم التنسيق لعملائهم ، ولكن سرعان ما أصبح واضحًا أنهم لا يخاطرون باستخدام تقنية غير معروفة بدون مواصفات رسمية. لذا قرر كروكفورد كتابته.
في عام 2002 ، اشترى كروكفورد نطاق
JSON.org ، ونشر بنية JSON ، ومثالًا على تنفيذ المحلل اللغوي. لا يزال الموقع يعمل ، على الرغم من أنه يظهر الآن رابطًا لمعيار JSON ECMA المعتمد في عام 2013. بالإضافة إلى إطلاق الموقع ، لم يفعل Crockford أي شيء تقريبًا للترويج لـ JSON ، ولكن سرعان ما كانت هناك عمليات تنفيذ لمحلل JSON في مجموعة متنوعة من لغات البرمجة. في البداية ، كان JSON مرتبطًا بشكل واضح بجافا سكريبت ، ولكن أصبح من الواضح بعد ذلك أنه مناسب تمامًا لتبادل البيانات بين الأزواج العشوائية للغات.
AJAX خاطئ
حصل JSON على دفعة كبيرة في عام 2005. ثم صمم مصمم ومطور يدعى Jesse James Garrett مصطلح AJAX في
مقالته . حاول التأكيد على أن AJAX ليست مجرد تقنية جديدة واحدة ، بل "العديد من التقنيات بطريقتها الخاصة مجتمعة بطرق جديدة قوية." وصف Garrett AJAX بأنه نهج جديد لتطوير تطبيقات الويب. في منشور مدونة ، وصف كيف يمكن للمطورين استخدام JavaScript و XMLHttpRequest لإنشاء المزيد من التطبيقات التفاعلية. ووصف أمثلة Gmail و Flickr للمواقع التي تعتمد على طرق AJAX.
بالطبع ، تعني "X" في AJAX XML. ولكن في الأسئلة والإجابات اللاحقة ، وصف غاريت JSON بأنه بديل مقبول تمامًا. وكتب أن "XML هي الأداة الأكثر فاعلية لتبادل البيانات لعميل AJAX ، ولكن يمكن تحقيق نفس التأثير باستخدام Javascript Object Notation أو أي تنسيق هيكلي مماثل للبيانات."
وجد المطورون حقًا أنه يمكنهم بسهولة استخدام JSON لإنشاء تطبيقات AJAX ، واختارها الكثيرون بدلاً من XML. ومن المفارقات أن الاهتمام بـ AJAX أدى إلى انفجار شعبية JSON. في هذا الوقت ، لفتت JSON انتباه عالم التدوين.
في عام 2006 ، اشتكى ديف وينر ، وهو مدون غزير ومنتج لعدد من تقنيات XML ، مثل RSS و XML-RPC ،
من أن JSON يعيد اختراع XML دون سبب وجيه:
"بالطبع ، يمكنني كتابة إجراء للتحليل [JSON] ، ولكن انظر إلى أي مدى ذهبوا إلى إعادة اختراع التكنولوجيا: لسبب ما ، XML ليس جيدًا بما يكفي بالنسبة لهم (أتساءل لماذا). من خلق هذه المحاكاة الساخرة؟ دعونا نجد شجرة ونعلق الرجل. الحق الآن ".
من السهل فهم خيبة أمل وينر. لم يكن XML محبوبًا على الإطلاق. حتى وينر نفسه
قال إنه لا يحب XML . ولكن تم تصميم XML كنظام عالمي لأي تطبيق يمكن أن تتخيله. XML هو بالفعل لغة معدنية تسمح لك بتحديد لغات المجال للتطبيقات الفردية - على سبيل المثال ، RSS و SOAP. يعتقد وينر أنه من المهم بناء توافق في الآراء لجميع الفوائد التي يجلبها تنسيق التبادل المشترك. في رأيه ، مرونة XML قادرة على تلبية أي احتياجات. ومع ذلك ، فإن JSON هو تنسيق لا يقدم مزايا على XML ، باستثناء الإزالة غير المرغوب فيها ، مما جعل XML مرنًا للغاية.
رأى كروكفورد منشور مدونة وينر وعلق. رداً على الاتهام القائل بأن JSON تعيد اختراع XML ، كتب كروكفورد:
" إعادة اختراع
العجلة أمر جيد لأنه يمكنك جعلها مستديرة .
"JSON مقابل XML
بحلول عام 2014 ، تم الاعتراف بـ JSON رسميًا كمعيار ECMA و RFC. حصل على نوع MIME. دخلت JSON في الدوريات الكبرى.
لماذا أصبح JSON أكثر شعبية من XML؟
في
JSON.org ، يدرج Crockford بعض
مزايا JSON عبر XML . يكتب أن JSON أسهل في الفهم من قبل كل من الأشخاص والآلات ، لأن تركيبها ضئيل وبنيته قابلة للتنبؤ.
يذكر المدونون الآخرون الإفراط في لغة XML و "علامة الضريبة". يجب أن تحتوي كل علامة افتتاحية في XML على علامة إغلاق ، مما يعني الكثير من المعلومات الزائدة. وهذا يجعل XML أكبر بكثير من مستند JSON المكافئ ، ولكن الأهم من ذلك أنه من الصعب قراءة مستند XML.
دعا كروكفورد ميزة أخرى رائعة لـ JSON: أنه تم تصميمه في الأصل كنسق لتبادل المعلومات المنظمة بين البرامج. على الرغم من استخدام XML للغرض نفسه ، فقد تم تطويره في الأصل كلغة ترميزية للمستند. لقد نشأت من SGML (لغة الترميز المعممة القياسية) ، والتي تطورت بدورها من لغة ترميز Scribe ، المخصصة لنص الترميز ، مثل LaTeX. في XML ، داخل العلامة ، قد يكون هناك ما يسمى "محتوى مختلط" ، أي نص يحتوي على علامات مضمنة تحيط بالكلمات أو العبارات. إنه يشبه محررًا يضع علامة على مخطوطة بعلامة حمراء أو زرقاء ، وهو نوع من الاستعارة للغة الترميزية. من ناحية أخرى ، لا يدعم JSON التناظرية الدقيقة للمحتوى المختلط ، مما يعني تبسيط الهيكل. يتم تمثيل المستند بشكل أفضل في شكل شجرة ، ولكن التخلي عن فكرة المستند ، تمكن كروكفورد من قصر JSON على القواميس والمصفوفات من العناصر المألوفة التي يستخدمها جميع المبرمجين لإنشاء برامجهم.
أخيرًا ، تخميني الخاص هو أن الناس لم يعجبهم تعقيد XML ، وكان ذلك حقًا بسبب تنوعه. للوهلة الأولى ، من الصعب التمييز بين XML نفسه ولغته الفرعية ، مثل RSS أو ATOM أو SOAP أو SVG. تحدد الأسطر الأولى من مستند XML النموذجي إصدار XML ، ثم اللغة الفرعية المحددة التي يجب أن يتطابق معها مستند XML. هذه العديد من الخيارات مقارنة بـ JSON ، وهي بسيطة للغاية لدرجة أنه لن تتم كتابة أي إصدار جديد من مواصفات JSON على الإطلاق. وقع مطورو XML ، في محاولة لإنشاء تنسيق واحد لتبادل البيانات لكل شيء ، ضحية لفخ المبرمج الكلاسيكي: التعقيدات التقنية المفرطة. XML عام جدًا بحيث يصعب استخدامه لشيء بسيط.
في عام 2000 ، بدأت حملة لجعل HTML تتماشى مع معيار XML. نشر مواصفات HTML المتوافق مع XML ، والمعروفة فيما بعد باسم XHTML. بدأ بعض صانعي المستعرضات على الفور دعم المعيار الجديد ، ولكن سرعان ما أصبح واضحًا أن عامة الناس الذين يعملون مع HTML لا يريدون تغيير عاداتهم. يتطلب المعيار الجديد التحقق من XHTML أكثر صرامة مما كان معتادًا على HTML ، ولكن العديد من المواقع تعتمد على قواعد HTML المجانية. بحلول عام 2009 ، توقف النشطاء عن محاولة كتابة نسخة ثانية من XHTML عندما أصبح من الواضح أن المستقبل يكمن في معيار HTML5 ، والذي لا يتطلب التوافق مع XML.
إذا نجحت جهود XHTML ، فربما يصبح XML تنسيقًا مشتركًا للبيانات ، كما يأمل مطوروها. تخيل عالماً تكون فيه مستندات HTML واستجابات واجهة برمجة التطبيقات بنفس البنية بالضبط. في مثل هذا العالم ، ربما لم يكن JSON شائعًا كما هو اليوم. لكني أعتبر فشل XHTML نوعًا من الهزيمة الأخلاقية لمعسكر XML. إذا لم يساعد XML HTML ، فقد تكون هناك أدوات أفضل للتطبيقات الأخرى. في العالم الواقعي ، من السهل فهم سبب نجاح تنسيق JSON البسيط والمتخصص للغاية.