Ответы:
Пользуйтесь XML над JSON, когда любое из них верно:
Пользуйтесь JSON над XML, когда все это верно:
Я использую JSON, если мне не нужно использовать XML. Его проще понять, и (поскольку это требует меньших затрат на настройку), его легче программировать для чтения и записи, если библиотеки доступны в вашем контексте, и теперь они довольно распространены.
Когда Amazon впервые представила свои каталоги как веб-сервис, они предложили как JSON, так и XML. Примерно 90% разработчиков выбрали JSON.
Учитывая ваш конкретный случай, когда вы уже выполняете JavaScript на стороне клиента, я бы остановился на JSON по следующим причинам:
Поскольку JSON является родным для javascript, вам придется писать меньше кода на стороне клиента - просто eval()(или, что еще лучше, JSON.parse()) строку JSON и получить объект, который вы можете использовать.
В то же время оценка JSON на стороне клиента будет более эффективной и, следовательно, более быстрой.
Сериализация JSON создает более короткие строки, чем XML. Использование JSON уменьшит объем данных, передаваемых по сети, и повысит производительность в этом отношении.
Вот некоторые дальнейшие чтения: http://www.subbu.org/blog/2006/08/json-vs-xml
eval()JSON большим нет-нет?
Некоторые другие вещи, с которыми я столкнулся в XML против JSON relm:
JSON очень хорош для
Это означает, что он стремится к массиву или вложенному массиву. Однако JSON отсутствует как
Таким образом, если вы объедините две или более службы JSON, могут возникнуть потенциальные конфликты пространства имен. При этом JSON может использоваться примерно для 90% тех же самых вещей, для которых XML может использоваться при обмене данными в моем опыте.
Обычно JSON более компактен и быстрее разбирается.
Предпочитаю XML, если:
Один важный случай (почти) XML: попытка обнаружить при отправке фрагментов HTML более выгодна, чем отправка необработанных данных. AHAH может творить чудеса в простых приложениях, но часто упускается из виду. Обычно этот стиль предполагает, что сервер отправляет фрагменты HTML, которые будут встроены в веб-страницу без обработки.
Обычно в случаях AHAH CSS максимально используется для визуального массажа фрагментов и реализации простых условий, таких как скрытие / отображение соответствующих частей фрагмента с использованием пользовательских или пользовательских настроек.
JSON легко и быстро разобрать. XML немного сложнее для анализа и медленнее для анализа и передачи (в большинстве случаев).
Поскольку вы используете jQuery, я предлагаю использовать JSON: jQuery может извлекать данные JSON и автоматически преобразовывать их в объект Javascript. Фактически, вы можете конвертировать данные JSON в объект Javascript, используя eval . Вам придется вручную пересекать XML (я не знаю, как это работает в Javascript, но это сложно / более раздражает в большинстве языков, с которыми я использовал библиотеки XML).
JSON всегда предпочтительнее с точки зрения обработки, которую клиентский браузер должен выполнять для анализа данных. Кроме того, JSON - это легкий формат обмена данными.
Синтаксический анализ XML всегда потребляет много ресурсов браузера и его следует избегать столько, сколько мы можем, если не требуется иное.
У меня есть пост в блоге на эту тему, подробно описывающий историю веб-протоколов (т. Е. SOAP, XML, JSON, REST, POX и т. Д.), Содержащий краткое изложение, а также некоторые преимущества и недостатки каждого из них: http://www.servicestack.net / mythz_blog /? р = 154
Я на самом деле думаю, что вы можете сделать много общего между XML и JSON, сравнивая различия между динамическим (JSON) и статическим (XML) языками.
По сути, XML является более строгим, более жестким форматом сериализации, который может быть дополнительно проверен с помощью сопровождающей схемы (которая является либо XSD, либо DTD). XSD довольно сложны и позволяют вам описывать множество различных типов, например, даты, время, перечисления, определяемые пользователем типы и даже наследование типов и т. Д. SOAP эффективно основывается на наборе функций XML, предоставляя стандартизированный способ описания ваших веб-сервисов ( например, типы и операции) через WSDL. Многословность и сложность спецификации WSDL означает, что ее разработка может быть более утомительной, но в то же время вам доступно гораздо больше инструментов, а большинство современных языков предоставляют автоматизированные инструменты для генерации прокси-серверов ваших клиентов, принимая на себя часть нагрузки. выкл при попытке взаимодействия с внешними сервисами.
Я бы по-прежнему рекомендовал использовать XML для своих веб-сервисов, если у вас есть четко определенная «корпоративная служба», которая не подвержена частым изменениям, или если к вашей веб-службе требуется доступ с разных языков.
При всех своих преимуществах XML также имеет свои недостатки. Он использует пространства имен для предоставления типизируемого расширяемого формата и позволяет указывать атрибуты и элементы в одном и том же документе. Наличие разных пространств имен в одном документе означает, что при использовании синтаксического анализатора XML для извлечения данных требуется много времени, вам также потребуется предоставить пространство имен для каждого элемента, который вы хотите получить / просмотреть. Он также экстраполирует полезную нагрузку, делая ее более многословной, чем она должна быть. Возможность вывода атрибутов, а также элементов означает, что ваши классы не отображаются должным образом в XML-документ. Одни только эти функции делают его плохо подходящим для большинства языков, что делает его более утомительным и громоздким в работе.
JSON, с другой стороны, является полной противоположностью XML во многих отношениях, поскольку он очень свободно набран и имеет простую поддержку только основных типов: Number, Bool, string, Objects и Arrays. Все остальное по сути должно вписываться в строку. Это не очень хорошо, когда вы пытаетесь общаться через языковые границы, так как вам нужно будет придерживаться некоторой внеполосной нестандартной спецификации, если вы хотите поддерживать более конкретные типы. На перевернутом его ограниченный набор функций делает хорошую программную посадку на большинстве языков - и идеально подходит для JavaScript в виде строки JSON можно eval'ed непосредственно в объект JavaScript.
Размер и производительность
У меня есть несколько доступных эталонных тестов для баз данных, сравнивающих размер и скорость между реализациями Microsoft и XML. По сути, XML более чем в 2 раза больше JSON, но в то же время выглядит так, будто Microsoft приложила немало усилий для оптимизации своего XML DataContractSerializer, поскольку он более чем на 30% быстрее, чем их JSON. Кажется, что вы должны сделать компромисс между размером и производительностью. Не довольный этим фактом, я решил написать свой собственный быстрый JsonSerializer, который теперь в 2,6 раза быстрее, чем MS XML - так что это лучшее из обоих миров :).
Когда вы идете по маршруту JSON, вы сталкиваетесь с теми же проблемами, с которыми XML столкнулся 10 лет назад:
Смешивание данных из двух разных источников в одном пакете JSON может привести к тому, что метки элементов столкнутся друг с другом. Смешайте упаковочный лист и счет, и вдруг адрес отправителя может означать что-то совсем другое. Вот почему у XML есть пространства имен .
Преобразование между различными структурами JSON потребует написания обычного кода. Более декларативный способ отображения данных облегчит работу. Вот почему XML имеет XSLT .
Описание структуры пакета JSON - его полей, типов данных и т. Д. - необходимо для того, чтобы люди могли подключиться к вашим услугам. Для этого важно иметь язык метаданных. Вот почему у XML есть схемы .
Забота о двух одновременных клиент-серверных разговорах. Если вы зададите серверу два вопроса и получите один ответ назад, как вы узнаете, на какой вопрос он отвечает? Вот почему XML имеет WS-корреляцию .
С первой строки на http://json.org/xml.html
Расширяемый язык разметки (XML) - это текстовый формат, полученный из стандартного обобщенного языка разметки (SGML). По сравнению с SGML XML прост. Язык разметки гипертекста (HTML), для сравнения, еще проще. Тем не менее, хороший справочник по HTML имеет толщину всего в один дюйм. Это потому, что форматирование и структурирование документов - сложное дело. , , ,
Очевидно, что JSON быстрее, но еще более ясно, что его трудно читать. Используйте JSON для скорости, используйте XML, если будет взаимодействие с человеком, и вы можете пожертвовать скоростью.
Я использую JSON для любой конфигурации, обмена данными или обмена сообщениями. Я использую XML, только если мне нужно по другим причинам или семантически разметить данные, подобные документам.
И XML, и JSON поддерживаются Microsoft. Литералы XML были новой интересной функцией в VB 9. В следующей версии ASP.NET 4.0 JSON является обязательным условием для использования возможностей шаблонизации на стороне клиента.
Из вопроса, который вы задали, кажется, JSON может быть для вас выбором, поскольку его легко обрабатывать на стороне клиента с или без jQuery.
Использование JSON
Использование XML
Я нашел эту статью на цифровом базаре действительно интересной.
Некоторые части статьи приведены ниже.
О JSON профи:
Если все, что вы хотите передать - это атомарные значения или списки или хэши атомарных значений, JSON обладает многими преимуществами XML: он прост в использовании через Интернет, поддерживает широкий спектр приложений, легко писать программы для обработки JSON, у него мало дополнительных функций, он понятен человеку и достаточно понятен, его дизайн формален и лаконичен, документы JSON просты в создании, и он использует Unicode. ...
О плюсах XML:
XML замечательно справляется со всем богатством неструктурированных данных. Меня совсем не волнует будущее XML, даже если его радостно отмечают кадры дизайнеров веб-API.
И я не могу устоять перед тем, чтобы сказать "Я же тебе говорил!" в моем столе. Я с нетерпением жду возможности увидеть, что делают JSON, когда их просят разработать более богатые API. Когда они захотят обменяться менее структурированными данными, будут ли они включать их в JSON? Я вижу случайные упоминания языка схемы для JSON, будут ли другие языки следовать? ...
Быстрые правила:
Объяснение:
Единственная роль JSON состоит в том, чтобы сериализовать объектно-ориентированные данные, используя типы данных, общие для большинства языков программирования: списки , хэши и скаляры , и с этой целью их действительно нельзя превзойти или улучшить. То есть «у JSON нет номера версии [поскольку] никаких изменений в грамматике JSON не ожидается». - Дуглас Крокфорд (Не могу побить это как знак того, что ты отлично делаешь свою работу)
Когда-то XML продавался как формат обмена данными, но рассмотрим два наиболее распространенных варианта использования: асинхронное взаимодействие клиент-сервер (AJAX) - JSON в значительной степени полностью заменил XML (X на самом деле должен быть J) и веб-сервисы. : JSON сделал XML избыточной альтернативой.
Другой вещью, для которой широко использовался XML, были файлы данных, доступные для записи / чтения (?) Для программ, но и здесь у вас есть более сжатый, более дружественный к программам, более удобный для человека формат в YAML, надмножестве JSON.
Так что для представления данных JSON превосходит XML по всем направлениям. Что тогда осталось для XML? Представление документов со смешанным содержимым, для чего оно и было предназначено .
Большинство новых веб-технологий работают с использованием JSON, поэтому, безусловно, это хорошая причина для использования JSON. Большим преимуществом является то, что в XML вы можете представлять одну и ту же информацию разными способами, что в JSON более просто.
Также JSON IMHO намного понятнее XML, что делает его для меня очевидным преимуществом. И если вы работаете с .NET, Json.NET - явный победитель, который поможет вам работать с JSON.