Нужна ли замена JSON? По следам статьи про KTV

Я, в целом, планировал публикацию про KTV для ссылки из других статей, чтобы, когда я их опубликую (например, вот эта, про S2) — можно было сослаться и не было бы вопросов, что такое KTV, и откуда оно возникло. Но тема оказалась больная. Поэтому я решил, что нужно немного подробнее рассказать, откуда возникла такая, странная на первый взгляд, идея.

Прикладываю к статье опросы. Помогите мне, пожалуйста, разобраться, в ситуации. :-)

Первая причина — Ångström Style System

Когда я делал ÅSS, нужен был формат данных для записи стилей. Я выбрал JSON. По большому количеству причин, главная из которых — очевидность. Формат хорошо и быстро (я сравнивал) парсится, плюс он крайне простой. Это значит, что я могу в те самые строки (у меня их две на пропертю, имя и значение) — запихнуть что угодно и потом это как угодно проинтерпретировать. С одной стороны это удобно, с другой — хрупкость этой системы совершенно неадекватна. Особенно, когда мы работаем со строго типизированным языком вроде Swift'а.

Мне также хотелось, чтобы проперти таки были пропертями, а не просто строками (массивами, ассоциативными массивами), то есть, чтобы их имена — были идентификаторами, а не чем-то-странным-с-пробелами. Это позволит в недалёком будущем, например, написать плагин для AppCode или для Sublime, которые будут проверять корректность их написания и подсвечивать, если что-то не так. Возможно будет автодополнение для @-ссылок, и так далее.

Также мне не хватало нескольких типов. Цвет — самый простой и самый нужный для стайлера, поэтому я с него начал и в KTV для S2. Но в KTV появятся и другие «нативные» типы.

Вторая причина — API

Работая в аутсорсинге, приходится постоянно реализовывать в мобильном приложении разные API. Степень «изобретательности» людей, которые его пишут порой не поддается никакой оценке, это фантастически странные конструкции. И главная причина таких конструкций — JSON. Он позволяет делать что угодно, как угодно. Умные люди стараются ограничить этот полёт мысли, получаются отличные проекты вроде http://jsonapi.org, но мне кажется, что до тех пор, пока форматом остаётся JSON — никуда ничего не сдвинется. Не зря ведь появились Kotlin, Swift, где даже null/nil просто так не присвоить, на это спецтип нужен.

Возьмём, к примеру, получение фида постов, скажем, блога про машинки. Там список постов с лайками, откуда есть ссылки на пользователей, их машины. У одного пользователя может быть 10 постов и 20 лайков. Стоит ли дублировать каждый раз пользователя в посте/лайке (и не только в посте, есть ведь пользователи, залайкавшие посты, или откомментировавшие)? Нет, точно не стоит. Мы это решали при помощи ID и плоские списки объектов, которые при парсинге вставляются, куда нужно. Но, как мне кажется, удобнее эту функциональность внести в формат. Тогда не придется каждый раз изобретать велосипед, будет очевидный способ реализации этой возможности.

Нужен ли новый формат вообще?

Статья показала, что, безусловно, нужн�� решение всех этих проблем. Поляризация мнений, отсутствие единого направления при решении этой общей проблемы, «а мне и так хорошо» — всё это напоминает мне споры XML vs JSON. Ни в коем случае не хочу сказать, что KTV — это штука, которая станет «следующим JSON'ом», но что-то нужно с этим сделать, чтобы каждый серверный и каждый клиентский разработчик (отмечу, клиенты — это не только веб, но ещё и мобильные приложения и другие сервера) перестал изобретать что-то своё. Слишком много сил тратится на взаимодействие и на изобретение.

При этом я считаю путь, выбранный ребятами на http://jsonapi.org, неправильным в долгосрочной перспективе. Сам по себе он отличный. Я не верю лишь, что удастся заставить следовать этим рекомендациям всё сообщество. Мы ведь такое уже проходили, это XML-RPC, это SOAP. Всё это — попытка зажать свободный формат рамками соглашений. Как показал опыт — не зажимается (точнее зажимается, но исключительно в рамках ентерпрайза). Только новый, жёсткий формат, который используется повсеместно, сможет заставить разработчиков синхронизироваться и формировать API одинаково. Хотя бы простые.

Поможет ли в этом направлении KTV — не знаю. Ему пара месяцев от роду, маленький ещё, глупый. Сможет вырасти в полноценный формат, будет отлично. Нет, тоже отлично, надеюсь, на его обломках появится другой, более качественный претендент.