JSON vs YAML vs XML: когда что на самом деле использовать

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

JSON был извлечён напрямую из синтаксиса объектных литералов JavaScript, и именно это происхождение объясняет, почему он стал форматом обмена данными по умолчанию для веб-API: любое окружение JavaScript способно разобрать его нативно вообще без всякой библиотеки, его грамматика достаточно мала, чтобы её можно было корректно реализовать за один вечер практически на любом другом языке, а его строгие правила — никаких комментариев, никаких висячих запятых, ключи только в двойных кавычках — означают, что парсеру JSON почти не приходится разрешать неоднозначность, что делает JSON одновременно быстрым для разбора и простым для правильной генерации. Та же самая строгость — главная слабость JSON для всего, что человек должен редактировать вручную напрямую: отсутствие комментариев означает отсутствие способа оставить поясняющую заметку в конфигурационном файле, а перегруженный пунктуацией синтаксис вложенных фигурных скобок становится по-настоящему трудно отслеживать взглядом, как только структура уходит глубже трёх-четырёх уровней.

Именно поэтому JSON доминирует в коммуникации между машинами — ответы API, обмен данными между сервисами, всё, что в первую очередь генерируется и потребляется кодом, а не читается и редактируется человеком, — оставаясь при этом несколько неуклюжим выбором для конфигурационных файлов, которые человеку предстоит поддерживать вручную.

YAML был спроектирован с противоположным приоритетом: читаемость для человека и простота ручного редактирования — ценой значительно более сложной спецификации разбора, чем у JSON. Он использует отступы вместо фигурных скобок для представления вложенности, поддерживает настоящие комментарии через `#` и допускает строки без кавычек в обычном случае — всё это делает хорошо оформленный файл YAML похожим почти на обычные структурированные заметки, а не на код, и именно поэтому YAML стал стандартом для конфигурационных файлов в огромной части инструментов разработчика: описания CI/CD-пайплайнов, манифесты оркестрации контейнеров, конфигурация приложений, которую человеку действительно нужно читать и напрямую изменять. Плата за это в том, что зависимость YAML от пробельных символов при определении структуры делает его по-настоящему хрупким при ручном редактировании — один неверно поставленный отступ незаметно меняет, какому блоку что-то принадлежит, вместо того чтобы выдать очевидную ошибку, — а его более снисходительная, богатая возможностями спецификация на протяжении многих лет порождала реальные, задокументированные несоответствия в разборе между разными библиотеками YAML — неоднозначность, для которой куда более строгая грамматика JSON попросту не оставляет места.

XML старше и JSON, и YAML и был спроектирован снова с иным приоритетом: строгая, проверяемая структура документа вместе со зрелой экосистемой сопутствующих стандартов — языки схем, способные провалидировать структуру документа ещё до того, как к нему притронется код приложения, XPath для запросов внутри документа, пространства имён для объединения словарей из разных источников без конфликтов имён. Эта глубина инструментария по-прежнему остаётся по-настоящему непревзойдённой у JSON или YAML в корпоративных, документо-ориентированных контекстах: отрасли со строгими требованиями к обмену данными, стандартизированными форматами документов и давно работающими унаследованными системами, построенными вокруг него, всё ещё полагаются на XML именно из-за этой зрелости валидации и инструментария, а не из чистой инерции. Хорошо известная плата за это — многословность: представление тех же вложенных данных в XML обычно требует заметно больше символов, чем эквивалентный JSON, поскольку каждому значению нужен открывающий и закрывающий тег вместо одного знака пунктуации, — и это главная причина, по которой XML уступил JSON роль формата по умолчанию для API по мере взросления веб-сервисов, когда размер полезной нагрузки и простота разбора стали более важными приоритетами, чем валидация в стиле документов.

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