Чому кожен вибирає JSON Over XML для jQuery? [зачинено]

Я думав, що XML дуже портативний, і його можна використовувати як міні-базу даних. Я бачив XML, що використовується скрізь. Я навіть бачу, як великі компанії переходять на JSON . Навіть Microsoft має інтегровану підтримку JSON. У чому вся галас над JSON?

В основному тому, що JSON впізнаний JavaScript JavaScript, він дійсно легкий, мінімалістичний та дуже портативний, оскільки він покладається лише на дві основні структури:

• Колекція пар імен / значень. У різних мовах це реалізується як об'єкт, запис, структура, словник, хеш-таблиця, список клавіш або асоціативний масив.
• Впорядкований список значень. У більшості мов це реалізується як масив, вектор, список чи послідовність.

XML насправді не починає світитися, поки ви не почнете змішувати різні схеми простору імен. Тоді ви бачите, як JSON починає падати, але якщо вам просто потрібен формат серіалізації для ваших даних, JSON менший, легший, легше читабельний і, як правило, швидший, ніж XML.

Я вважаю, що велика перевага JSON над XML полягає в тому, що я не повинен вирішувати, як форматувати дані. Як показали деякі, існує чимало способів зробити навіть прості структури даних у XML - як елементи, як значення атрибутів тощо. Тоді вам доведеться документувати це, написати XML-схему або Relax NG або якусь іншу лайну ... Це безлад.

XML може мати свої достоїнства, але для обміну базовими даними JSON є набагато компактнішим і прямим. Як розробник Python, не існує невідповідності імпедансу між простими типами даних у JSON та Python. Тож якби я писав серверний обробник для запиту AJAX, який запитував про снігові умови для певного гірськолижного курорту, я створив би словник наступним чином:

conditions = {
    'new_snow_24': 5.0,
    'new_snow_48': 8.5,
    'base_depth': 88.0,
    'comments': 'Deep and steep!',
    'chains_required': True,
}
return simplejson.dumps(conditions)   # Encode and dump `conditions` as a JSON string

При перекладі через JSON (використовуючи бібліотеку типу "simplejson" для Python), отримана структура JSON виглядає майже однаково (за винятком JSON, булеві букви мають нижній регістр).

Розшифровка цієї структури вимагає лише аналізатора JSON, будь то Javascript або Objective-C для нативного додатка iPhone або C # або клієнта Python. Поплавці трактуватимуться як поплавці, струни як струнні, а булеві - булеві. Використовуючи бібліотеку 'simplejson' в Python, simplejson.loads(some_json_string)заява поверне мені повну структуру даних, як я щойно зробив у наведеному вище прикладі.

Якби я написав XML, я мав би вирішити, чи робити елементи чи атрибути. Обидва наведені нижче дії:

<conditions>
    <new-snow-24>5</new-snow-24>
    <new-snow-48>8.5</new-snow-48>
    <chains-required>yes</chains-required>
    <comments>deep and steep!</comments>
</conditions>

<conditions newSnow24="5" newSnow48="8.5" chainsRequired="yes">
   <comments>deep and steep!</comments>
</conditions>

Тому я не тільки повинен думати про дані, які, можливо, я хочу надіслати клієнтові, я мушу думати, як їх форматувати. XML, хоч і простіший за звичайний SGML, будучи більш суворим зі своїми правилами, все ще надає занадто багато способів думати про ці дані. Тоді мені доведеться піти про її створення. Я не міг просто взяти словник Python (або іншу просту структуру даних) і сказати «перейди, вклади себе у свій XML». Я не зміг отримати XML-документ і негайно сказати «перейдіть, зробіть себе об’єктами та структурами даних», не написавши спеціальний аналізатор або не вимагаючи додаткових накладних витрат на XML Schema / Relax NG та інші подібні болі.

Недолік цього полягає в тому, що кодувати і декодувати дані в JSON просто набагато простіше і набагато прямо, особливо для швидких обмінів. Це може стосуватися більше людей, що походять з динамічного мовного фону, оскільки основні типи даних (списки, словники тощо), вбудовані в JavaScript / JSON, безпосередньо відображають однакові або подібні типи даних у Python, Perl, Ruby тощо.

Продуктивність JSON не сильно відрізняється від XML для більшості випадків використання, JSON не дуже підходить і читається для глибоко гніздових структур ... Ви зіткнетесь з цим]]]}], що ускладнює налагодження

Він легкий порівняно з XML. Якщо вам потрібно масштабувати, зменшіть свої пропускну здатність!

Порівняйте JSON

 [
      {
           color: "red",
           value: "#f00"
      },
      {
           color: "green",
           value: "#0f0"
      },
      {
           color: "blue",
           value: "#00f"
      },
      {
           color: "cyan",
           value: "#0ff"
      },
      {
           color: "magenta",
           value: "#f0f"
      },
      {
           color: "yellow",
           value: "#ff0"
      },
      {
           color: "black",
           value: "#000"
      }
 ]

до XML:

 <colors>
      <color >
           <name>red</name>
           <value>#f00</value>
      </color>
      <color >
           <name>green</name>
           <value>#0f0</value>
      </color>
      <color >
           <name>blue</name>
           <value>#00f</value>
      </color>
      <color >
           <name>cyan</name>
           <value>#0ff</value>
      </color>
      <color >
           <name>magenta</name>
           <value>#f0f</value>
      </color>
      <color >
           <name>yellow</name>
           <value>#ff0</value>
      </color>
      <color >
           <name>black</name>
           <value>#000</value>
      </color>
 </colors>

Просто анекдот з мого особистого досвіду:

Я написав невеликий каталог Javascript, спочатку з даними в XML, а потім адаптував його до використання JSON, щоб я міг запускати їх поруч і порівнювати швидкості з Firebug. JSON виявився приблизно в 3 рази швидшим (350-400 мс проти 1200-1300 мс для відображення всіх даних). Крім того, як зазначають інші, JSON набагато простіше на очах, а розмір файлу був на 25% меншим завдяки меншій розмітці.

 <colors>
      <color name='red'     value='#f00'/>
      <color name='green'   value='#0f0'/>
      <color name='blue'    value='#00f'/>
      <color name='cyan'    value='#0ff'/>
      <color name='magenta' value='#f0f'/>
      <color name='yellow'  value='#ff0'/>
      <color name='black'   value='#000'/>
 </colors>

З атрибутами XML приємно. Але чомусь домашній XML, як правило, на 100% зроблений з елементів, і некрасивий.

Легке споживання JavaScript може бути однією з причин ..

JSON найкраще для споживання даних у веб-додатках із веб-сервісів за своїм розміром та простотою використання, особливо завдяки вбудованій підтримці JavaScript . Уявіть собі накладні обчислення для розбору фрагмента XML порівняно з миттєвим пошуком у JSON.

Дуже хороший приклад - JSON-P. Ви можете отримати дані з веб-сервісу, завернутого у виклик функції зворотного виклику, як my_callback({"color": "blue", "shape":"square"});усередині <script>тегу, що динамічно генерується, щоб дані можна було безпосередньо споживати у функції my_callback(). Неможливо навіть наблизитися до цієї зручності за допомогою XML.

XML був би вибором формату для великих документів, де ви маєте основу візуалізації сторінок даних у декількох форматах за допомогою XSLT. XML також може використовуватися з файлами конфігурації додатків для читабельності серед багатьох інших застосувань.

Тут ніхто не згадав про головну перевагу XML: правила перевірки (DTD, XSD). Мої висновки, використавши обидва:

• JSON ідеально підходить для ajax, особливо якщо ви розробляєте і серверну, і сторону клієнтів. Ви в основному створюєте js-об’єкти прямо в серверному сценарії!
• XML сяє у корпоративному середовищі, коли вам доведеться встановлювати стандарти обміну даними між великими бюрократичними організаціями. Часто одна сторона розробляє свою частину місяцями раніше іншої, тому вона дійсно виграє від підтвердження своїх запитів проти узгодженого XSD. Також у великих корпораціях передача даних часто перекладається між різними системами. Це також сила XML, думаю XSLT. Приклад: перетворення без коду в JSON: p

Звичайно, розробляється json-схема, але вбудованої підтримки ви ніде не знайдете.

Я фанат обох, вони мають просто різну силу.

Тепер, коли є кодери та декодери JSON для більшості мов, немає жодної причини НЕ використовувати JSON для використання там, де це має сенс (і це, мабуть, 90% випадків використання для XML).

Я навіть чув про те, що рядки JSON використовуються у великих базах даних SQL, щоб спростити зміни схеми.

Чесно кажучи, між JSON та XML не так багато різниці в тому, що вони можуть представляти всі типи даних. Однак XML синтаксично більший за JSON, і це робить його важчим, ніж JSON.

JSON не має імпедансу-невідповідності програмуванню JavaScript. JSON може містити цілі числа, рядки, списки, масиви. XML - це лише елементи та вузли, які потрібно розібрати на цілі числа тощо, перш ніж їх можна буде споживати.

Обидва чудові та дуже портативні. Однак JSON набирає популярності, оскільки в більшості випадків серіалізується на менше символів (що перетворюється на швидший час доставки), а оскільки він відповідає синтаксису об'єкта JavaScript, його можна безпосередньо перекласти в об'єкт пам'яті, що робить Ajax набагато простішим здійснити.

XML як і раніше чудовий. JSON - лише "найновіший і найбільший" порівняно з XML.

Легко розбирається JavaScript і він легкий (документ у JSON менший, ніж документ XML, який містить ті самі дані.)

JSON ефективно серіалізований JavaScript, завдяки чому ви можете eval (aJsonString) безпосередньо в об’єкт JavaScript. Всередині веб-переглядача JSON без розуму підходить для JavaScript. У той же час JavaScript є дуже слабко типізованою динамічною мовою і не може споконвічно скористатися всією доступною інформацією про тип, що міститься в документі Xml / Xsd. Ці додаткові метадані (що чудово підходить для сумісності) - це перешкода в JavaScript, що робить її більш втомливою та кумедною для роботи.

Розмір проти продуктивності

Якщо ви перебуваєте в веб-переглядачі, JSON швидше серіалізувати / десеріалізувати, оскільки він простіший, компактніший і важливіше підтримується. У мене є кілька орієнтирів бази даних на північному повітрі, які порівнюють розмір та швидкість між різними доступними серіалізаторами. У бібліотеці базових класів серіалізатор XML DataContract Microsoft на Microsoft на 30% швидший, ніж у JSON. Хоча це стосується більше зусиль, які Microsoft вклав у свій XML-серіалізатор, оскільки мені вдалося розробити JsonSerializer, який на 2,6 рази швидший, ніж його XML. Що стосується корисних навантажень на основі орієнтирів, то схоже, що XML приблизно перевищує 2 разирозмір JSON. Однак це може швидко вибухнути, якщо ваша корисна навантаження XML використовує багато різних просторів імен в одному документі.

XML - це зміїна олія в більшості ситуацій. JSON дає вам більшість переваг без набряку.

Одна головна перевага, крім зазначених тут. Для одних і тих же даних є кілька способів представити їх як XML-файл, але лише один спосіб за допомогою JSON, усуває неоднозначність :)

Я далеко не експерт, але з різних компаній, над якими працював, ми зазвичай використовуємо XML у невеликих середовищах даних або конфігураційних значень (web.config - чудовий приклад).

Якщо у вас є велика кількість даних, вам потрібно буде звітувати про ці дані. І XML не є чудовим джерелом для звітування. У грандіозній схемі речей схоже, що транзакційну базу даних простіше звітувати / шукати, ніж XML.

Це має сенс? Як я вже говорив вище, я не фахівець, але, зі свого досвіду, це, мабуть, так і є. Крім того, я вважаю, що інтегрована підтримка Microsoft JSON завдяки хвилі розробників, що переходять на сторону клієнта або сценарії дій для покращення наочності інтерфейсу ( Ajax ), а Ajax Microsoft не використовується так багато, як інші бібліотеки, такі як jQuery і MooTools ( YUI Yahoo також в цій суміші) завдяки їх прекрасній інтеграції серіалізаційних об'єктів за допомогою JSON.

Я вважаю, що зараз пишу код, реалізуючи серіалізатор JSON у своєму коді VB. ШЛЯХО надто просто, і з точки зору оновлення / модифікації ви не можете його обіграти. Я думаю, що це спосіб Microsoft підтримувати нас залежними від VS. Нещодавно я перетворив корпоративну програму на використання Ajax (через jQuery) та використання формату JSON. На це знадобилося приблизно 2 тижні. Я насправді дякую Microsoft за інтеграцію, оскільки без цього мені довелося б написати зовсім небагато зайвого коду.