> Жсон удобен для передачи/сериализации данных как замена хмл.Нет он не замена XML и, судя по всему, никогда ей не станет. Для того чтобы быть заменой, ему бы схему бы заиметь для начала. Потом не плохо было бы научиться запросам и трансформациям без помощи свежих стандартов XML и переконвертации JSON<->XML для этой задачи (см стандарты XSLT 3.0). Он может заменить малюсенькие SOAP-вебсервисы при условии что они стейтлес и занимаются проливкой потока данных. Люди которые видят JSON как ЗАМЕНУ XML, обычно никогда не видели большого JSON-документа. При виде файлика уже больше 65 ГБ эти клоуны регулярки писать садятся.
У JSON есть 3 обоснованных применения
1. У вас там малюсенькие экземпляры объектов, которые передаются через стейтлесс апи. Например всё API реализовано как RESTful, и производительность самой операции сериализации/десериализации в пределах погрешности.
2. У вас есть JavaScript, в браузере или на сервере, не важно. Он ему родной и очень удобный.
3. У вас язык который не умеет по-нормальному сериализировать свои объекты (Python) и не имеет вменяемой поддержки XML (Python) и при этом не может подключить внешнюю библиотеку на нормальном языке без требований к написанию тонны обвязок (Python).
В остальном он бесполезен, хотя всё лучше чем YAML. =)
> Для конфигов, как и хмл, он паршив.
Я по своему опыту расскажу откуда берутся такие кадры. Видел таких.
Сидит питонист и пишет очередной свой скрипт, которому нужен конфиг. Про то что люди (живые человеки) любят редактировать простые документы типа INI в формате "ключ=значение" они понимают, но им лень парсить текстовый документ в словарь, то ли дело json который разом делает json.dump(). А что там с кодировками, nonASCII-символами, забытыми запятыми и скобочками они знать не хотят. СлОжНа-сЛоЖнА!
Другой вариант - мамкины-оркестраторы. Эти кадры отличаются от девопсов тем, что используют системы оркестрации для задач удалённого управления. Есть 2 подхода к конфигурированию:
- API-based configuration
- Document-based configuration
Первое предполагает фиксированное API удаленного управления, а второе - текстовая конфигурация в пачке документов. У каждого подхода есть свои достоинства и недостатки, как обычно, но мамкиному-оркестратору это не важно. Ему нужно использовать подходы API-based для программ с конфигурацией на основе документов.
То есть у них есть много программ внутри ОС, которые используют конфигурационные файлы, но они не хотят работать с ними как с документами. Не хотят их версионировать, а когда пытаются прикрутить API, не хотят решать вопросы конкурентного доступа (реализовывать транзакционность изменения конфигурации) им нужно быстренько настроечку поправить в конфиге по удаленке на паре сервачков. И опять регулярки, и опять sed-ы. Эх вот было бы оно всё в json, да мы бы как бы весь этот конфиг быстренько распарсили... эхх... тьфу!
> За исключением приложений у которых гуишная или консольная прога для конфигов и правка человеком на прямую не предполагается.
Или есть API для изменения этой конфигурации, вроде того же WS-Management (Dell iDRAC, Intel AMT, Microsoft WinRM и иже с ними). Просто когда я вижу человека, который хочет писать текстовые конфиги в JSON и отдавать их пользователям, я, исходя из того что повидал, предполагаю, что он пытается написать API для управления этой программой, но делает это костылями, а когда не работает ставит подпорки. И, самое главное, не забыть автоматически перепнуть, если упало.
