я видел с некоторыми json парсерами идут кастомные валидаторы, кому не лень было делать. правда в таком случае парсеры тормозные, для эстетических целей.
может уже стандартец народили? типа jq

а с чего ты взял, что у  них нет генератора кода? там такой json что без генератора никак. + сверху обфусцируется (ну не совсем там другой термин - распарсить глазами можно).

схемы почти все, что существуют — расширяемые. Ничего согласовывать не надо, если придерживаться несложных правил.

всегда существует это самое "если", которое в теории позволит избежать боли, но на практике встречается редко-редко...

теория?

почему сразу теория? так сложно представить, что такие есть в этом мире коллективы, где проще выкинуть схему, что бы избежать проблем которые она порождает из-за частых изменений формата, чем как-то упорядочить этот хаос?

это как раз практика. гордится тут, понятное дело, нечем, но тем не менее оно вот так

хреновые коммуникации, бюрократия, заказчик у которого 7 пятниц на неделе - подчеркни нужное, а то и все сразу.

а практически такие ситуации возникали, что что-то работало на схемах, а потом это переколбасили на ручную проверку полей в жейсончике? Или все разваливается на этапе теории?

это очень сложно

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

полный перепис

частное изменение без схемы? такое возможно только в системе без памяти даже в милисекунды. если память присутствует, то придется делать всё тоже самое что делает формат с поддержкой схем и версий.

да во весь рост. я врать не буду, у меня джава, эрланг исключительно как хобби, но не думаю, что это сильно влияет. практический пример - несколько сервисов общающихся жсонами со схемами. вроде схемы полезны. дальше их, как попки-чебурашки, просто лепят по инерции везде и всюду - потому что есть методическая инструкция, стандарт менеджмента качества, и прочие страшные слова, которые не имеют к инженеграм никакого отношения. параллельно идет процесс разделения, декомпозиции, рефачинга этих сервисов... короче не круг в какой-то момент обнаруживается, что огромная часть взаимодействий стала внутренней, потоки данных и так имеют валидации в соседних сервисах, которые не доверяют только схеме, но и лепят еще свои валидации, что б наверняка. и вот это внутреннее как-то переделать хрен получится, потому что там аццкий клубок из этих схем, которые закреплены в 33 документах и 100500 местах где их валидируют

когда плюнуди по послабили этот схематозный психоз процесс как-то сдвинулся с мертвой точки, а когда оказалось, что валидировать-то особо нечего, поскольку где-то 50% трафика составляют айдишники, которые либо UUID, либо мусор и проще это прям по месту проверить, то вопрос "а нахрена тут вообщзе схема?"  повис в воздухе

но любители "стандартов менеджмента качества" лютуют, им хоцца - им кажется, что одно наличие схемы это качество повышает...

естественно есть и обратные примеры, когда согласованный с заказчиком ( который является внешним по отношению к системе клиентом, причем нихрена не доверенным) согласован формат взаимодействия, то он отливается в виде схемы, и если на вход летит какой-то мусор, потому что ну это же Заказчик, у него там что угодно может быть, то такой запрос отваливается еще на подлете, и саппорт показывает заказчику фигу, лог, в котором сказано про инвалидность входного мусора, и отправляет чинить свои баги. и это хорошо, потому что внутренний контур живет и в ус не дует

то есть основная мысль - это не "схема полезна" или "схема бесполезна", а "нужно понять чего от схемы в конкретном случае больше - пользы или вреда - и действовать соответственно"

фух, все =)

А у вас все эти валидации и схемы проходят по границам команд, или это один человек сам с собой согласует?