Comments 51
Есть ваш сервис настолько нагружен что формат данных играет роль значит надо переходить на протобафы.
Вероятность что это так довольна мала на самом деле. Для всех типовых сервисов нагрузка на формирования ответа в любом формате настолько мала что ее можно игнорировать. Сотни пользователей это мизерная нагрузка. 10 РПС в прыжке будет хотя бы?
До примерно 1000 РПС можно использовать то что удобнее или то что уже есть и в проде. Что-то менять или оптимизировать нет смысла. Дальше уже стоит подумать.
Если встает проблема в объемах передаваемых данных - то в первую очередь включите HTTP компрессию.
Возможно после этого проблема ваша будет решена и ничего сверху переделывать не придётся.
XML ещё и очень плохо глазами читается и его сложно руками править. Но вообще да, к чему полумеры, нужна скорость, тогда protobuf + grpc.
Насчет валидации - JSON Schema, как мне кажется, не так уж плохо развилась за последнее время. Ее пока не забюрократизировали так тщательно как XML Schema, но думаю, что это вопрос времени
Для парсера форматы XML и JSON не имеют существенных различий. На мой взгляд, с точки зрения разбора, XML менее требователен к ресурсам, поскольку явно указаны начало и конец тегов.
Возможно, проблема в используемых библиотеках, а не в формате файлов.
Думаю, ваши обобщения не верны.
XML более требователен, поскольку явно указаны начало и конец тегов
Для парсера то можно универсально написать. Знач структуру.
Но попробуйте например такую задачу, как всосать json или XML в вариантный тип данных - паскалевски variant (допустим у меня в языке через варианты-наследники IUnknown реализуются объекты имеющие именованные свойства, то есть абсолютно любая древовидная иерархия возможна внутри variant). Если структура данных заранее не известна, то Json содержит информацию о том что данные - массив чего либо и это отлично отпарсится в varray. В XML же, массивы передаются просто перечислением нескольких одинаково называемых элементов расположенных в dom друг за другом. А теперь пытаемся придумать как отличить в XML просто элемент от массива из этого элемента длиной 1.....
Мне например такой способ неизвестен. В итоге XML в общем виде в variant не засосать...
А ещё у XML есть отличный мир самодостаточных языков, базирующихся на том же XML: XSD, XSLT и т.д.
Попробуйте сделать HTML из JSON без приседаний. В мире XML это решает XSLT.
Для адресации по DOM-дереву есть XPath. Да, можно сказать что есть и JPath, но это достаточно убогая пародия на оригинал: в нём просто нету многих вещей вроде навигации банальной навигации к родителям и поиска на произвольной глубине, фильтрации выборки и многого другого.
Он просто вышел из моды в угоду стильно-модно-молодёжного. А жаль.
Там были объективные причины. Во-первых куча разных версий спецификаций и абсолютная неопределённость в их поддержке со стороны окружения. В браузерах одни особенности и ограничения, на сервере - другие. Тот же libxslt усложнился настолько, что его уже боялись трогать, чтобы не сломать обратную совместимость и практически перестали развивать. При этом разных болячек в нем хоть отбавляй. Во-вторых, проблемы с производительностью и потреблением памяти парсеров XML все же были реальностью, которые крайне затратно решать со стороны прикладного разработчика. Замена XML на JSON улучшала ситуацию на порядок и практически задаром.
Пробовал как-то трансформировать XML при помощи XSLT. Это жесть. Какая-то дичайшая помесь функциональщины и процедурщины(по воспоминаниям), может я конечно просто не осилил, но врагу на таком писать не пожелаю.
Писал как-то эти XSLT, это просто ужас ужасный, абсолютно неудобный язык, проще уже преобразования делать средствами настоящих языков программирования.
Тоже самое касается и превращения JSON в HTML, это проще сделать при помощи любого ЯП.
XML просто неадекватно сложный формат смешивающий в себе все на свете.
XSLT, судя по комментам, люди не любят. А я его уже не помню, но я был в большом восторге от XQuery. Были две великолепные книжки для IBM DB2, которые его объясняли. Наверное, для других систем не было таких хороших книжек, раз про XQuery никто не вспоминает.
Делали как-то большой проект на XQuery, даже десктоп приложение на нем писали со встроенной XML DB для работы оффлайн, тойже что и на сервере работала, eXist-db называется. Код был общий и на сервере и на клиенте. Я туда, в саму БД, даже GIT встраивал =) для кода, XQuery код тоже в БД был.
И все же, я бы не назвал JSON лёгким в смысле длинны. Сходу можно было бы убрать кавычки из названий полей, убрать повторяющиеся названия полей и т.п.
Плюс убрать лишние двоеточия, экранирование спецстмволов, добавить многострочный текст и получится tree
А квадратные и фигурные скобки заменить на круглые! И избавиться от двоеточий ;)
SAX параметры не кушают память как DOM и достаточно быстры в обработке, опять же xslt удобен для преобразований
"Древний артефакт" появился в 1998 году, а "выбор современного мира" в 1999-м. С одной стороны, XML, конечно, несколько старше, но один год на фоне 26 не значит почти ничего.
А по поводу "черепашьей скорости обработки XML" - вы просто не умеет обрабатывать его быстро. Советую почитать про SAX-парсеры.
До этого просто был ещё SGML с ещё 80ых
А по поводу "черепашьей скорости обработки XML" - вы просто не умеет обрабатывать его быстро
Они всё ещё дают производительность в пределах сотни-другой мегабайт в секунду на ядро. simdjson же предоставляет 2.5GBps+.
XML это по своей сути размеченный текст. Что, между прочим, явно обозначено в названии - eXtensible Markup Language. Тэги и атрибуты - разметка, а основа, то есть то, что собственно передаётся из точки А в точку Б, это текст между тегами.
Использование XML для передачи структурированных данных - чистой воды абьюзинг этой технологии. Пока не было JSON-а, в это за неимением лучшего имело смысл играться. Сейчас использованию языка разметки для кодирования стуктур данных не может быть оправдания.
На картинке с чуваком в оранжевой куртке не просто xml, а сообщение soap. Soap протокол да, имел дофига наворотов (например то, что клиента можно было легко сгенерировать по wsdl файлу, или url сервиса, вместо того чтоб писать его вручную) но и был весьма медленным.
Если не использовать soap, а просто записать в xml те же данные, что записаны в json, то разница в объеме сообщения будет минимальна, ну может процентов 10.
То, что эти 10% как-то повлияли на производительность при сотнях клиентов, да еще и таким драматическим способом, извините, выдумки.
Скажем так. XML гораздо более выразительный, и описывать сложные структуры данных на нем не в пример удобнее. Другое дело, что настолько сложные структуры, для которых недостаточно описания JSON, встречаются очень редко.
XML -- это группа стандартов с продуманной семантикой, а JSON в оригинале просто был куском JS кода, внезапно ставший индустриальным стандартом ввиду нативной поддержки на фронте. На данный момент мы наблюдаем неудачные стихийные попытки восполнить отсутствующую семантику при помощи JSON path, JSON schema, поделку openapi, etc. Сравнивать эти два формата по принципу "кто круче" по меньшей мере некорректно.
Я так и не понял, что можно классно описать в xml, чего нельзя в json? Я без иронии.
Аж залогиниться пришлось. Дальше по пунктам статьи.
Для начала - то что описано в 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. Вот пусть он там и остается.
После того, как глазками увидел с какой бешеной скоростью разбирается 100+Мб xml выгрузка из openstreetmap в рассказы про то, как всё тормозит из-за xml верю с большим скрипом...
На мой взгляд как-то по-детски написана статья - "Xml бяка, Json цаца".
Как правило транспортный Xml - это результат сериализации размеченного объекта. Имена тегов покороче, атрибуты вместо элементов, слово за слово и Xml уже не сильно отличается от Json по объёму. И в целом, если DTO - ботлнек, то это очень уж специальный случай. Обычно затыкается все на базе или в коде написанном без оглядки на перфоманс.
Я помню волну восторга неофитов, которые прикоснулись к “великому убийце SOAP - Json!“. Прям гибко все, компактно, никакого тебе мучения со схемами и WSDL. А потом первый восторг схлынул, и оказалось, что формат таки все равно надо описывать, причём как-то платформ-независимо. И валидировать вход и выход. И сгенерить клиента по описанию сервиса. И вот уже и Json Schema, и Swagger/open API.
Картина маслом - дело не в формате, а в типичных задачах, возникающих при взаимодействии удалённых систем.
А что насчëт YAML формата?
Я так и не увидел из статьи кейсов, где json был бы плох. Перечисляются кейсы когда можно найти применение xml, но непонятно почему с ними не может справиться json.
XML против JSON: как «слишком много тегов» убивает скорость