Аж залогиниться пришлось. Дальше по пунктам статьи.
Для начала - то что описано в JSON примере не является тем же типом данных, который описан в XML, это ессли дословно. Вероятно может быть он описывает похожую сущность, но то что описано - совсем не идентично. Ближе всего "по смыслу" равнозначные примеры в разных форматах должны быть вот такими:
ЭтоXML
Это JSON
И тот и тот текст отформатирован при помощи стандартного редактора. Согласитесь - по разному смотрится. И с точки зрения компактности тоже :) То, что с точки зрения техники примеры из статьи точно не эквивалентны вы можете убедиться поискав в JSON теги Item и Order (как минимум). В XML есть почти фиксированная строка объявления того что он есть XML
Объявление XML, которое автор у себя забыла. В ее случае по стандарту это просто какой то текст а не XML
Если ее убрать. и так же убрать лишнее форматирование и незначимые пробелы (те что не в адресе) и в XML и в JSON, то XML из исправленного примера состоит из 144 символов а "компактный " JSON из 156. Странная компактность получается, не находите?
Возможности описания данных в XML значительно больше чем аналогичные в JSON. Пространства имен например. В дополнение к этому XML схема позволяет абсолютно однозначно в техническом смысле описать набор данных, которые вы хотите представить. XML парсер дает возможность однозначно их валидировать (без написания кода разбора типа данных вообще). Аналога XSLT (язык трансформации при помощи парсера) и XPath (выражения которые позволяют однозначно определить где находится один элемент относительно другого) для JSON не существует в принципе. Идет сравнение несравнимых вещей.
Про "заставил сервер думать" - это вообще даже не смешно. SOAP - это протокол передачи. Четко стандартизированный. REST - это просто "архитектурный стиль" как написано в Wiki. Для примера, пусть автор найдет какой-нибудь REST сервис написанный в каком-нибудь Тайване (например) или в Шри-Ланке и попробует найти там же его понятное описание и потом реализовать обмен. А потом попробует найти SOAP веб сервис, и набрать его адресную строку с ?wsdl в конце. Оцените удобство, иногда это помогает.
Каждому формату свое место - тут я согласен. JSON - JavaScript Object Notatin. Вот пусть он там и остается.
С точки зрения RYA - Не помню использования "Капитан" в терминологии. Видимо это относится к военным кораблям. Утверждения описанные в вашем учебнике не верны даже для IYT. Шкиппер может брать деньги за управление, но не любой. (Bareboat на которого вы отучились не может), про п.2 не в курсе - всегда считал что это относится военным судам, 3 - тоже не в курсе.
Аж залогиниться пришлось. Дальше по пунктам статьи.
Для начала - то что описано в JSON примере не является тем же типом данных, который описан в XML, это ессли дословно. Вероятно может быть он описывает похожую сущность, но то что описано - совсем не идентично. Ближе всего "по смыслу" равнозначные примеры в разных форматах должны быть вот такими:
И тот и тот текст отформатирован при помощи стандартного редактора. Согласитесь - по разному смотрится. И с точки зрения компактности тоже :) То, что с точки зрения техники примеры из статьи точно не эквивалентны вы можете убедиться поискав в JSON теги Item и Order (как минимум). В XML есть почти фиксированная строка объявления того что он есть XML
Если ее убрать. и так же убрать лишнее форматирование и незначимые пробелы (те что не в адресе) и в XML и в JSON, то XML из исправленного примера состоит из 144 символов а "компактный " JSON из 156. Странная компактность получается, не находите?
Возможности описания данных в XML значительно больше чем аналогичные в JSON. Пространства имен например. В дополнение к этому XML схема позволяет абсолютно однозначно в техническом смысле описать набор данных, которые вы хотите представить. XML парсер дает возможность однозначно их валидировать (без написания кода разбора типа данных вообще). Аналога XSLT (язык трансформации при помощи парсера) и XPath (выражения которые позволяют однозначно определить где находится один элемент относительно другого) для JSON не существует в принципе. Идет сравнение несравнимых вещей.
Про "заставил сервер думать" - это вообще даже не смешно. SOAP - это протокол передачи. Четко стандартизированный. REST - это просто "архитектурный стиль" как написано в Wiki. Для примера, пусть автор найдет какой-нибудь REST сервис написанный в каком-нибудь Тайване (например) или в Шри-Ланке и попробует найти там же его понятное описание и потом реализовать обмен. А потом попробует найти SOAP веб сервис, и набрать его адресную строку с ?wsdl в конце. Оцените удобство, иногда это помогает.
Каждому формату свое место - тут я согласен. JSON - JavaScript Object Notatin. Вот пусть он там и остается.
С точки зрения RYA - Не помню использования "Капитан" в терминологии. Видимо это относится к военным кораблям. Утверждения описанные в вашем учебнике не верны даже для IYT. Шкиппер может брать деньги за управление, но не любой. (Bareboat на которого вы отучились не может), про п.2 не в курсе - всегда считал что это относится военным судам, 3 - тоже не в курсе.