У меня есть запись в блоге на эту тему с подробным описанием истории веб-протоколов (т. Е. 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 может быть eval'ed непосредственно в объекте JavaScript.
Размер и производительность
У меня есть доступных тестов базы данных для северного ветра , сравнивающих размер и скорость между реализациями Microsoft и XML JSON. По сути, XML более чем в 2 раза больше JSON, но в то же время выглядит так, будто Microsoft приложила много усилий для оптимизации своего XML DataContractSerializer, так как
это более чем на 30% быстрее, чем у JSON. Кажется, что вы должны сделать компромисс между размером и производительностью. Не довольный этим фактом, я решил написать свой собственный быстрый JsonSerializer , который теперь в 2,6 раза быстрее, чем MS XML - так что лучший из обоих миров:).