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

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

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

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

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

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

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

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

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

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

• пары имя/значение
• вложенные пары

Это означает, что он похож на массив или вложенный массив. Однако JSON отсутствует как

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня есть доступные JsonSerializer, который теперь в 2,6 раза быстрее, чем MS XML один - настолько лучший из обоих миров:).

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

Из первой строки в http://json.org/xml.html

Расширяемый язык разметки (XML) - это текстовый формат, полученный на основе стандартного обобщенного языка разметки (SGML). По сравнению с SGML XML прост. HyperText Markup Language (HTML), для сравнения, еще проще. Тем не менее, хороший справочник по HTML - толщиной в дюйм. Это связано с тем, что форматирование и структурирование документов - это сложный бизнес.,.

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

от JSON - последние футы

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

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

Преобразование между различными JSON структурам потребуется писать мирский код. Более декларативный способ для сопоставления данных упрощается работа. Вот почему XML имеет XSLT.

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

Выполнение двух одновременных сеансы клиент-сервер забота. Если вы спросите сервер два вопросы и получить один ответ, как знаете ли вы, на какой вопрос он отвечает? Вот почему XML имеет WS-корреляцию.

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

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

• JSON: формат данных программы для программы
• YAML (JSON superset): формат данных от человека к программе
• XML: формат разметки документа

Объяснение:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые части статьи приведены ниже.

О JSON-профи:

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

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

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

И я не могу сопротивляться тому, что я сказал вам об этом! отметить в моем стол письменный. Я с нетерпением жду того, что делают люди JSON, когда они попросил разработать более богатые API. Когда они хотят меньше обмениваться структурированные данные, будут ли они обучать его в JSON? Я вижу случайные упоминания языка схемы для JSON, последуют ли другие языки?...