JSON против YAML: Почему JSON занял трон обмена данными?
"Человеку гораздо удобнее читать YAML, но почему для API-коммуникаций используется только JSON?"
"В чем сильные стороны YAML, и по какой причине JSON стал стандартом?"
1. Начало войны форматов данных
В прошлом разработчикам требовался "общий стандарт" для обмена данными между системами. На заре развития эту роль занимал XML.
<person>
<name>Alice</name>
<age>25</age>
<skills>
<skill>Python</skill>
<skill>Django</skill>
</skills>
</person>
Однако XML был слишком многословен и тяжеловесен, требуя закрытия каждого тега. Его было утомительно читать. В этот момент появились альтернативы: JSON и YAML.
2. JSON: Стандарт обмена веб-данными
В 2001 году Дуглас Крокфорд, вдохновившись объектным представлением в JavaScript, создал JSON. Его ключевой идеей было: "максимально легкий, удобный для машинного чтения".
JSON добился успеха по нескольким очевидным причинам: * Непревзойденная легкость: Передает только данные, без лишних "украшений". * Идеальная совместимость с вебом: В браузере (JavaScript) его можно было напрямую преобразовать в объект без дополнительных библиотек. * Интуитивное сопоставление: Структура практически идентична структурам данных в современных языках, таких как словари Python или объекты JS.
Особенно с ростом популярности REST API в вебе, JSON фактически стал универсальным языком.
3. YAML: Формат, созданный для чтения человеком
Были и те, кто сосредоточился на "удобстве чтения человеком" больше, чем JSON. Из стремления писать без фигурных скобок и кавычек, более чисто, родился YAML.
name: Alice
age: 25
skills:
- Python
- Django
Характеристики YAML очевидны:
* Высочайшая читаемость: Благодаря использованию отступов (Indentation) текст выглядит очень аккуратно.
* Поддержка комментариев (#): Большое преимущество – возможность добавлять пояснения, чего нет в JSON.
* Лидер в файлах конфигурации: Благодаря своей читаемости он полностью доминирует в форматах конфигураций инфраструктуры, таких как Kubernetes, Docker, GitHub Actions.
Но почему же он не смог превзойти JSON в обмене данными (API)?
4. Реальные причины, по которым YAML уступил в обмене данными
Во-первых, строгость отступов (пробелы против табуляции). В JSON структуру определяют скобки, тогда как в YAML невидимый пробел определяет структуру. При обмене сложными данными одна неправильная табуляция может привести к аду отладки.
Во-вторых, скорость парсинга и ресурсы. Синтаксис JSON прост, поэтому его парсер очень легок и быстр. В свою очередь, синтаксис YAML настолько обширен и сложен (включая возможность выполнения кода), что его анализ требует больше памяти и ресурсов CPU. В среде API, где обмениваются большими объемами данных, это критично.
В-третьих, проблемы безопасности. YAML может включать функции для прямого вызова объектов определенных языков, помимо простых данных. Это потенциально может привести к уязвимостям безопасности, таким как удаленное выполнение кода (RCE), что делает его непригодным для API, обменивающихся данными с неопределенным кругом лиц.
5. В конечном итоге, вопрос в "правильном применении"
Если JSON – король обмена данными, то YAML – король файлов конфигурации. Каждый из них прочно утвердился в своей области.
- Когда следует использовать JSON: Для обмена данными через веб-API, хранения в базах данных NoSQL, передачи данных клиенту.
- Когда следует использовать YAML: Для файлов конфигурации проекта (
docker-compose.yml), скриптов CI/CD, документации, управляемой человеком.
Даже в Django Rest Framework (DRF) можно добавить YAMLRenderer, но по умолчанию всегда используется JSONRenderer. Ведь данные должны быть точными и быстрыми.
Заключение: В одной строке
"Для общения между машинами (API) – JSON, для общения между человеком и машиной (конфигурация) – YAML."
Рекомендуемые статьи: