Когда предпочесть JSON XML?

JSON - это собственная кодировка для javascript. Это должно быть намного быстрее и проще в работе.

JSON легко и быстро анализировать. XML немного сложнее анализировать и медленнее анализировать и передавать (в большинстве случаев).

Поскольку вы используете jQuery, я предлагаю использовать JSON: jQuery может извлекать данные JSON и автоматически преобразовывать их в объект Javascript. Фактически, вы можете преобразовать данные JSON в объект Javascript с помощью eval. XML придется пересекать вручную (я не знаю, как это работает в Javascript, но это сложно / раздражает больше на большинстве языков, с которыми я использовал библиотеки XML).

Я использую JSON, если мне не нужно использовать XML. Это проще для понимания и (поскольку это требует меньших затрат на настройку) легче программировать для чтения и записи, если библиотеки доступны в вашем контексте, а сейчас они довольно распространены.

Когда Amazon впервые представила свои каталоги как веб-сервис, они предложили как JSON, так и XML. Примерно 90% разработчиков выбрали JSON.

Я использую JSON для любой конфигурации, обмена данными или обмена сообщениями. Я использую XML только в случае необходимости по другим причинам или для семантической разметки данных, подобных документу.

Учитывая ваш конкретный случай, когда вы уже используете javascript на стороне клиента, я бы выбрал JSON по следующим причинам:

• Поскольку JSON является родным для javascript вам придется писать меньше кода на на стороне клиента - просто eval() (или, еще лучше, JSON.parse()) JSON строку и получить объект можно использовать.

• В то же время оценка JSON на на стороне клиента будет больше эффективный, а значит, и более быстрый.

• Сериализация JSON короче строки, чем XML. Использование JSON будет уменьшить объем выполняемых данных по проводам и улучшить производительность в этом отношении.

Вот еще кое-что: http://www.subbu.org/blog/2006/08/json-vs-xml

Обычно JSON более компактен и быстрее анализируется.

Предпочитайте XML, если:

• Вам необходимо обработать данные на клиенте, и вы можете использовать для этого XSL. Скорее всего, цепочка XML + XSL будет работать быстрее, чем JSON + JavaScript, особенно для больших фрагментов данных.
  • Хороший вариант - преобразовать данные в фрагмент HTML.
• Различные унаследованные кейсы:
  • Существует уже существующий XML-сервис, и по некоторым причинам его сложно переписать с помощью JSON.
  • Вы должны отправить эти данные обратно как XML после некоторой легкой обработки с использованием пользовательского ввода.

Один важный случай (почти) XML: попытка определить, когда отправка HTML-фрагментов более выгодна, чем отправка необработанных данных. АХ АХ может творить чудеса в простых приложениях, но его часто упускают из виду. Обычно этот стиль предполагает, что сервер отправляет фрагменты HTML, которые будут встроены в веб-страницу без обработки.

Обычно в случаях AHAH CSS используется по максимуму для визуального массажа сниппетов и реализации простых условных выражений, таких как скрытие / отображение соответствующих частей сниппета с использованием настроек, специфичных для пользователя или приложения.

Я бы выбрал XML вместо JSON, если мне нужно проверить блок входящих данных, потому что XML изначально поддерживает это через XSD.

Предпочитайте XML вместо JSON, если верно любое из этих условий:

• Вам нужна проверка сообщения
• Вы используете XSLT
• Ваши сообщения содержат много размеченного текста
• Вам необходимо взаимодействовать со средами, не поддерживающими JSON.

Если все это верно, отдайте предпочтение JSON перед XML:

• Сообщения не нужно проверять, или проверка их десериализации проста.
• Вы не преобразуете сообщения или преобразуете их десериализацию просто.
• Ваши сообщения - это в основном данные, а не размеченный текст
• Конечные точки обмена сообщениями имеют хорошие инструменты JSON.

Некоторые другие вещи, с которыми я столкнулся в XML vs JSON relm:

JSON очень хорош для

• пары имя / значение
• гнездование этих пар

Это означает, что ему нравятся массивы или вложенные массивы. Однако в JSON отсутствуют оба

• атрибуты
• пространство имен

Поэтому, если вы объедините две или более службы JSON, могут возникнуть потенциальные конфликты пространств имен. При этом, по моему опыту, JSON можно использовать примерно для 90% тех же вещей, для которых можно использовать XML при обмене данными.

JSON всегда предпочтительнее с точки зрения обработки, которую клиентский браузер должен выполнять для анализа данных. Кроме того, JSON - это легкий формат обмена данными.

Анализ XML всегда потребляет много ресурсов браузера, и его следует избегать, насколько это возможно, если не требуется иное.

И XML, и JSON поддерживаются Microsoft. Литералы XML были новой интересной функцией в VB 9. В грядущей версии ASP.NET 4.0 JSON является обязательным условием для использования возможностей создания шаблонов на стороне клиента.

Из заданного вами вопроса кажется, что JSON может быть вашим выбором, поскольку его легко обрабатывать на стороне клиента с jQuery или без него.

из JSON - последние ноги

When you go down the JSON route, you run into the same issues that XML faced 10 years ago:

Mixing data from two different sources into one JSON packet can cause element labels to bump into each other. Mix up a packing slip and an invoice, and suddenly the From address may mean something quite different. That’s why XML has namespaces.

Converting between different JSON structures would require writing mundane code. A more declarative way to map data would make the job easier. That’s why XML has XSLT.

Describing a JSON packet’s structure—its fields, data types, etc.—is necessary in order for people to hook into your services. It’s essential to have a metadata language for this. That’s why XML has Schemas.

Carrying on two simultaneous client-server conversations takes care. If you ask the server two questions and get one answer back, how do you know what question it answers? That’s why XML has WS-Correlation.

У меня есть сообщение в блоге на эту тему, в котором подробно описывается история веб-протоколов (например, SOAP, XML, JSON, REST, POX и т. д.), В котором приводится сводка, а также некоторые преимущества и недостатки каждого из них: http://www.servicestack.net/mythz_blog/?p=154

Я действительно думаю, что вы можете найти много общего между XML и JSON, сравнив различия между динамическими (JSON) и статическими (XML) языками.

По сути, XML - это более строгий формат сериализации, который можно дополнительно проверить с помощью сопроводительной схемы (которая является либо XSD, либо DTD). XSD довольно сложны и позволяют описывать множество различных типов, например. Даты, время, перечисления, типы, определяемые пользователем, и даже наследование типов и т. д. SOAP эффективно строится на основе набора функций XML, обеспечивая стандартизованный способ описания ваших веб-сервисов (например, типов и операций) через WSDL. Многословие и сложность спецификации WSDL означает, что разработка может быть более утомительной, но в то же время вам доступно гораздо больше инструментов, и большинство современных языков предоставляют автоматизированные инструменты для генерации ваших клиентских прокси, что берет на себя часть бремени. выключен при попытке взаимодействия с внешними службами. (Хотя в то же время я считаю, что сгенерированные прокси сами по себе являются обузой при работе с часто меняющимися веб-службами).

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

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

С другой стороны, JSON является полной противоположностью XML во многих отношениях, поскольку он очень слабо типизирован и имеет простую поддержку только основных типов: Number, Bool, string, Objects и Arrays. Все остальное, по сути, должно укладываться в строку. Это не очень хорошо, когда вы пытаетесь общаться через языковые границы, поскольку вам нужно будет придерживаться некоторых нестандартных спецификаций вне диапазона, если вы хотите поддерживать более конкретные типы. С другой стороны, его ограниченный набор функций обеспечивает хорошую программную совместимость с большинством языков - и идеально подходит для JavaScript, поскольку строка JSON может быть оценен непосредственно в объекте JavaScript.

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

У меня есть доступны тесты базы данных Northwind, сравнивающий размер и скорость между реализациями Microsoft XML и JSON. По сути, XML более чем в 2 раза превышает размер JSON, но в то же время похоже, что Microsoft приложила много усилий для оптимизации своего XML DataContractSerializer как это более чем на 30% быстрее, чем их JSON. Кажется, что вам нужно найти компромисс между размером и производительностью. Не довольный этим фактом, я решил написать свой собственный быстрый JsonSerializer, который теперь в 2,6 раза быстрее, чем MS XML - так что лучше обоих :).

Использование JSON

• Если данные должны использоваться JavaScript в браузере.
• Модель данных простая и несложная (слишком много составных объектов).

Использование XML

• В основном в среде типа SOA, где вы интегрируете несколько сервисов на разнородных платформах и технологиях.
• SOAP имеет то преимущество, что его можно передавать по разным протоколы кроме HTTP.
• Простой в использовании инструмент преобразования модели данных, такой как XSLT, XSL-FO и т. д.
• Много поддержки базы данных для хранения / запроса (XQuery) данных XML.
• XML - это очень зрелый формат данных, поэтому вы найдете множество инструментов для поддержки любого варианта использования, о котором вы только можете подумать.

Я нашел эта статья на цифровом базаре действительно интересным.

Некоторые отрывки из статьи цитируются ниже.

О плюсах JSON:

If all you want to pass around are atomic values or lists or hashes of atomic values, JSON has many of the advantages of XML: it’s straightforwardly usable over the Internet, supports a wide variety of applications, it’s easy to write programs to process JSON, it has few optional features, it’s human-legible and reasonably clear, its design is formal and concise, JSON documents are easy to create, and it uses Unicode. ...

О преимуществах XML:

XML deals remarkably well with the full richness of unstructured data. I’m not worried about the future of XML at all even if its death is gleefully celebrated by a cadre of web API designers.

And I can’t resist tucking an "I told you so!" token away in my desk. I look forward to seeing what the JSON folks do when they are asked to develop richer APIs. When they want to exchange less well strucured data, will they shoehorn it into JSON? I see occasional mentions of a schema language for JSON, will other languages follow? ...

Быстрые правила:

• JSON: межпрограммный формат данных
• YAML (расширенный набор JSON): формат данных человек-программа
• Формат разметки документа XML:

Объяснение:

Единственная роль JSON - сериализовать объектно-ориентированные данные с использованием типов данных, общих для большинства языков программирования: списки, хеши и скаляры, и для этой цели его действительно невозможно превзойти или улучшить. То есть «JSON не имеет номера версии [поскольку] никаких изменений грамматики JSON не ожидается». - Дуглас Крокфорд (Не могу победить это как признак того, что вы отлично справляетесь со своей работой)

XML когда-то продавался как формат обмена данными, но рассмотрим два наиболее распространенных варианта использования: Асинхронная связь клиент-сервер (AJAX) - JSON практически полностью заменил XML (X действительно должен быть J), и веб-сервисы: JSON сделал XML избыточной альтернативой. .

Другой вещью, для которой широко использовался XML, были файлы данных, доступные для записи / чтения (?) Для программ, но и здесь у вас есть более сжатый, более удобный для программирования, более удобный для человека формат в YAML, надмножество JSON.

Таким образом, для представления данных JSON превосходит XML по всем направлениям. Что же тогда остается для XML? Представление документа смешанного содержания, то есть был предназначен для.

С первой строки на http://json.org/xml.html

Extensible Markup Language (XML) is a text format derived from Standard Generalized Markup Language (SGML). Compared to SGML, XML is simple. HyperText Markup Language (HTML), by comparison, is even simpler. Even so, a good reference book on HTML is an inch thick. This is because the formatting and structuring of documents is a complicated business. . . .

Очевидно, что JSON быстрее, но еще более очевидно, что его трудно читать. Используйте JSON для скорости, используйте XML, если будет взаимодействие с людьми, и вы можете пожертвовать скоростью.

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

Также JSON IMHO намного понятнее, чем XML, что дает мне явное преимущество. А если вы работаете с .NET, Json.NET - явный победитель, который поможет вам работать с JSON.

Я вижу здесь некую предвзятую догму. Похоже, что ответы на этот вопрос слишком упрощены для xml и исходят только из контекста веб-разработки (что имеет смысл для вопроса), поэтому я подумал, что id предлагает некоторую дополнительную информацию на случай, если кто-то пересечет это и ему нужен ответ для данных сериализация в других контекстах.

Вот жесткие правила:

XML, безусловно, не возможно, более мощный. Поэтому используйте его, когда ваша модель данных достаточно сложна, чтобы требовать следующих функций:

1. Поддержка пространств имен
2. Поддержка объектной ориентации, т.е. наследования / полиморфизма
3. Поддержка включения и расширения для повторного использования сложных типов.
4. Поддержка, необходимая для надежной, зрелой и полной системы проверки схемы.
   • Система проверки схемы w3c намного лучше справляется со схемой JSON и имеет больше литературы для ее изучения.
5. Поддержка моделирования данных документа со смешанным содержанием и записи, как моделирование данных.

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

TL: DR, XML может делать все, что может json, но тяжелее. Обратное просто неверно. Да, Json проще и поэтому используется чаще, но это не значит, что он может вытеснить XML. В том случае, когда я столкнулся с этим годом, 2020, json не подходил для нашего варианта использования, нам буквально нужен XML. Если нужно, я могу поговорить об этом подробнее. Ура и удачи.