JSON формат, а стоит ли его читать?
Сегодня был задан вопрос на ruSO и касается отображения файла JSON в удобочитаемом варианте для человека. Вопрос занял мою голову на весь день, да, и отрицать популярность данного формата на сегодняшний день глупо. Поговорил с коллегами, попытался узнать: кто-нибудь в реальных задачах применяет pretty-printed JSON-файлы. Ответ оказался отрицательным. Но нашлись примеры борьбы с излишним количеством знаков у front-end разработчиков на javascript и это вроде как рутинная обработка и они не обращают внимание на это.
Поскольку вышеуказанный вопрос касался непосредственно python, я полез читать что же написано в документации по этому поводу, а точнее параметра indent. И вот что там:
.... and object members will be pretty-printed with that indent level.
Да, я допускаю, что представление структуры JSON в виде иерархии очень показательно при обучении, но после программисты продолжают использовать данные с кучей пробелов и переводами строк. Пример из последнего: один товарищ пытается отослать команды на кастомную PLC систему (она принимает JSON, но что под капотом у нас доступа нет) и возмущается, что ничего не работает. Чистим JSON -> все работает.
Как я это вижу и почему я не хочу читать данные файлы глазами. Все дело в том, что дальнейшая обработка полученных данных заключена в работе с простым словарем (в терминологии python). И в любом случае я буду перебирать ключ:значение. Я могу узнать у словаря существует ли ключ, какой тип данных лежит под этим ключем, забрать данные, поместить данные и т.д.
Поскольку я постоянно с этим сталкиваюсь и мне приходится подчищать и обрабатывать такого типа файлы, возникает вопрос: существует ли реальная задача (здесь я понимаю "не учебная"), где необходимо было бы использовать красоту в иерархии JSON-файла? Может кто-то сталкивался? Может быть я действительно чего-то не замечаю.
Ответы (1 шт):
Как по любому вопросу, который засел в голове, пришлось провести мини-исследование. Темой которого стало: "Нужен ли pretty-printed JSON?" Для ленивых сразу спойлер - мой ответ: "Да, нужен". Отправной точкой стали комментарии оставленные под вопросом.
Итак, по порядку:
- JSON - текстовый формат обмена данными, основанный на JavaScript. Как и многие другие текстовые форматы, JSON легко читается людьми. Wiki. Основой стал
XML, а цель создать облегченную версию формата обмена данными. Т.е. изначально закладывалась идея возможности чтения без различных кодировщиков и интерпретаторов. - JSON позволяет легко читать структуру запросов\ответов к API. Да, в документации к различным API содержатся структуры запросов именно в
pretty-printedJSON. Это действительно удобно и сокращает время на создание\понимание запросов. (по мотивам комментария от Roman Konovalov) - Конфигурации. Здесь не все так однозначно и есть противники использования JSON формата для конфиг файлов, но
ASP.Net coreиспользует, а также нашел еще парочку открытых примеров. Но очень расстроился, когда понял, что пример лежит перед самым носом. VSCode позволяет конфигурировать себя с помощью JSON, черт.F1->Preferences: Open Settings (JSON). Удобно, ли, читать и форматировать? Естественно. (по мотивам комментариев от Roman Konovalov, MaxU) - Различного рода отладка. Здесь я остался при том мнении, что читать я не буду. Получение данных и дальнейшая обработка - задачи, которые решаются при помощи написания кода. Отлавливать глазами, а потом писать обработку? Можно, же, сразу писать обработку, реализовывать исключения для непонятных данных и проч. Но чтобы к этому прийти, сдается мне, что по началу я тоже читал глазами.
- Для самого
pythonaнашел библиотеку для использования переменных сред из JSON файла. json-environ. Удобство чтения и использования на лицо. Вряд ли лучшее решение для меня, но все же.
Для баз данных ничего интересного не нашел кроме того, что функционал различных DB поддерживается для работы с JSON (postgres, SQL Server). Насколько необходимо иметь красивый JSON, не понятно.
Что по итогу:
Вопрос изначально не был состоятельным. Если закладывают в формат на старте возможность, зачем в принципе это отрицать. Если я не использую pretty-printed JSON - это абсолютно не значит, что никому это не нужно. Но полностью согласен, что "... гонять по сети и хранить следует json в компактном виде" (Alexander Petrov).