Почему все выбирают JSON вместо XML для jQuery? [закрыто]

Я думал, что XML очень переносим и может использоваться в качестве мини-базы данных. Я видел XML, используемый везде. Я даже вижу, как крупные компании переходят на JSON . Даже в Microsoft встроена поддержка JSON. Что за шумиха над JSON?

В основном потому, что JSON изначально распознается 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, в котором вы можете вызывать (aJsonString) непосредственно в объект JavaScript. Внутри браузера JSON не представляет никакой сложности. Он идеально подходит для JavaScript. В то же время JavaScript является очень свободно типизированным динамическим языком и не может изначально использовать все доступные сведения о конкретном типе, содержащиеся в документе Xml / Xsd. Эти дополнительные метаданные (которые отлично подходят для взаимодействия) являются помехой в JavaScript, что делает работу с ними более утомительной и трудоемкой.

Размер против производительности

Если вы работаете в браузере, JSON быстрее сериализуется / десериализуется, поскольку он проще, компактнее и, что более важно, изначально поддерживается. У меня есть несколько доступных тестов базы данных Northwind, сравнивающих размер и скорость между различными доступными сериализаторами. В библиотеке базовых классов Microsoft XML DataContract сериализатор более чем на 30% быстрее, чем их JSON. Хотя это больше связано с усилиями, которые Microsoft вложила в их XML-сериализатор, поскольку я смог разработать JsonSerializer, который более чем в 2,6 раза быстрее, чем их XML. Что касается полезных нагрузок, основанных на тестах, то выглядит так, как будто XML примерно в 2 раза большеразмер JSON. Однако это может быстро сорваться, если ваша полезная нагрузка XML использует много разных пространств имен в одном и том же документе.

В большинстве случаев XML является раздутым змеиным маслом. JSON дает вам большинство преимуществ без раздувания.

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

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

Обычно, когда у вас большие объемы данных, вы захотите сообщить об этих данных. И XML не является отличным источником для отчетности. В общей схеме кажется, что транзакционная база данных легче сообщать / искать по сравнению с XML.

Имеет ли это смысл? Как я уже сказал выше, я не эксперт, но по моему опыту, похоже, это так. Кроме того, я полагаю, что Microsoft интегрировала поддержку JSON из-за волны разработчиков, переходящих на клиентские или скриптовые действия для улучшения визуальных элементов пользовательского интерфейса ( Ajax ), и Microsoft Ajax используется не так часто, как другие библиотеки, такие как jQuery и MooTools ( YUI от Yahoo также в этой смеси) из-за их прекрасной интеграции сериализуемых объектов с использованием JSON.

Я сейчас пишу код, реализующий сериализатор JSON в своем VB-коде. Это слишком просто, и с точки зрения улучшения / модификации вы не можете победить его. Я думаю, это способ Microsoft удерживать нас зависимыми от VS. Я недавно преобразовал корпоративное приложение в использование Ajax (через jQuery) и использование формата JSON. Это заняло примерно 2 недели. Я на самом деле благодарю Microsoft за ее интеграцию, потому что без нее мне пришлось бы написать совсем немного дополнительного кода.