Как стать автором
Обновить

Комментарии 36

JSON Schema при первом взгляде кажетя очень полезной, но на практике очень частые паттерны выражаются с её помощью очень неудобно или вообще никак. Самый первый, наверное, nullable типы.


Плюс, популярный формат OpenAPI (aka Swagger) с JSON Schema совместим лишь частично, что вынуждает писать две очень похожих схемы или пользоваться только пересечением возможностей.

Спасибо за ваш комментарий.
Плюс, популярный формат OpenAPI (aka Swagger) с JSON Schema совместим лишь частично, что вынуждает писать две очень похожих схемы или пользоваться только пересечением возможностей.

Думаю, это повод, чтобы обратиться к сообществу OpenAPI (aka Swagger) и предложить доработаться :)

В целом я бы сказал, что спецификация схемы OpenAPI (aka Swagger) если не более продвинутая, то более удобная, хотя некоторые вещи из "оригинала" не реализованы, емнип.

Сообщество уже эту проблему недавно как раз решило. https://github.com/OAI/OpenAPI-Specification/pull/1977


JSON Schema Draft 2019-09 has been published for a while, and after much deliberation we got the folks at OpenAPI to merge #1977 for v3.1. This will make OpenAPI a small superset, and no longer a subset/superset/sideset. Of those five keywords, two are deprecated (nullable and example).
Phil Sturgeon
НЛО прилетело и опубликовало эту надпись здесь
Спасибо! Интересный инструмент! Внесу его в список полезных ссылок, если позволите?
НЛО прилетело и опубликовало эту надпись здесь
ну тогда и аналоги из мира angular туда же:

Спасибо и вам! тоже пополнила список вашим дополнением)
То, что легко можно описать через XML Schema, не всегда будет тривиальной задачей повторить с помощью JSON Schema, если вообще это будет возможно.

А что вам позволяет делать такие выводы?

Собственно проблема простая — нужно понять отличия XSD от JSON-schema. Какие возможности XSD отсутствуют в JSON-schema? И наоборот.
— А что вам позволяет делать такие выводы?
— Собственный опыт. В частности, даже приводимые «справочники» дались не легко.
Главное отличие json от xsd — это отсутствие комплексных типов. Чтобы это отсутствие компенсировать, нужно будет использовать ключевые слова, обеспечивающие ссылочность схем. И то ограничение, что схема — это тип элемента «объект», может накладывать некоторые ограничения при включении ее в другую схему, там, к примеру, где нужно использовать другой тип. В xsd — это комплексный тип, который мы можем назначить элементу, а в json это, по факту, подключение элемента (типа object).
Т.е. приходится думать немного иначе, чем, когда проектируется xsd схема.
И есть сложность с описанием, например, дефолтных параметров, если они в списке задаются.
"enum": [	
"administrator",
"superuser"
],
"enumNames": [
"Администратор",
"Пользователь-администратор с ограниченным доступом"
]

Не очень удобно, на мой взгляд, так как описание не поддерживается в таком случае средствами визуализации. Но тем не менее, решение есть.
Комплексный тип можно изобразить при помощи id/ref. Ещё вижу ключ type, но он видимо только для JS типов? Хотя опять же, JS тип тоже может быть комплексным.

То есть средства есть. Хотя их поддержка в инструментах, возможно, оставляет желать лучшего.

Большое спасибо за статью, добавил в закладки.


Не могу удержаться, чтобы не процитировать: «Всё гениальное просто, и всё простое гениально».

Уж простите, но не могу удержаться, чтобы не прокомментировать… Конъюнкция двух общеутвердительных суждений штука провокационная. :)


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


Вот мне кажется, что построение множеств обычных и бесконечных чисел в ZFC это пример чуть-ли не сверхъестественной гениальности. Но простым это назвать язык не поворачивается, чуть мозги не сломал, пока разбирался.


Простота, кстати, тоже не так уж и проста. Вот, например, есть поговорка "простота хуже воровства". :)


Имхо, саму цитату можно смело отнести к множеству высказываний-паразитов, которые отличаются звучностью и запоминаемостью, а в буквальном смысле либо противоречивы, либо ложны, либо бессмысленны. А в небуквальном смысле их можно натягивать чуть ли не на всё, что угодно. Примеры — "я знаю, что ничего не знаю", "мысль изречённая есть ложь", "если не можете объяснить 6-летнему, то сами не понимаете", и в таком духе. Так, в каком-нибудь споре, когда либо лень, либо трудно привести контраргумент, можно "с достоинством" уйти, оставив что-то типа 'Как сказал великий Тютчев "мысль изречённая есть ложь", а это всё слова'.


Кстати, чья цитата? Гугл пытается доказать, что Геббельса. Того самого… )))


P.S. Сорри за оффтопик.

С огромным удовольствием прочла ваш комментарий)))
Ваш ход мыслей на тему гениальности приглашает к обсуждению).
Вы мастерски задаете конвергентные вопросы, и мне большого усилия стоит, чтобы не «поконфронтировать» вам немного. Но я удержусь), иначе обсуждение может действительно уйти далеко за пределы обсуждения темы данной статьи).
Спасибо за ваш комментарий)
А еще JSON Schema можно генерировать в рантайме, если например значения enum будут известны только на этапе выполнения программы. За счет этого схема станет строже.
Спасибо за комментарий.
Если откровенно, но мне не очень понятен сценарий. Не затруднит привести пример и пояснить, за счет чего схема станет строже при ее генерации в run-time? Как технически на это влияет заполнение enum на этапе выполнения программы? Очень интересно)

Например, если у нас что-то вроде конечного автомата или workflow, в enum status могут быть только допустимые здесь и сейчас значения, а не все теоритечески возможные.

Мой случай это примитивная СУБД, хранящая данные в JSON. И например там есть коллекции с ограничением «внешний ключ». При загрузке базы данных в память генерируется JSON Schema и проверяет всю базу на корректность. Причем там используется смешанный подход. Что-то через JSON Schema проверяется, что-то напрямую из данных. Некоторые виды проверок довольно муторно делать через JSON Schema.
Из готовой JSON Schema можно генерировать DTO; я использовал jsonschema2pojo
Спасибо! Тоже добавила в список «полезностей».
Спасибо за ваш комментарий!
В список не могу добавить, к сожалению, т.к. статья посвящена json schema.
Добрый день, можно ли по JSON schema генерировать JSON сообщения? Есть ли в нём аналоги input как в XSD?
Простите, уже нашел ответы, прочитав внимательнее вашу статью. Спасибо!
Здорово! Я очень рада, что статья полезна!
Подскажите бесплатные аналоги Альтовы для визуализации таких схем?
Добрый день.
Откровенно говоря, не искала аналоги, алтовы мне достаточно всегда было. Но если поискать, то вот такие варианты выдает поиск:
archive.codeplex.com/?p=jsonviewer
codebeautify.org/jsonviewer
countwordsfree.com/jsonviewer
прочитал вашу статью, проникся и решил организовать первичное тестирование по схемам через альтову. и вот что имею.Такой вот забавный факт. Я имею JSONschema и пытаюсь по ней отвалидировать JSON. Работаю в Altova. Зачем я валидирую? ну я пытаюсь организовать первичное тестирование со стороны заказчика таким образом. В JSON schema я указываю соотвественно type и прочие параметры длины строк (maxLenght), максимума (maximum) и минимума (minimum). По-моему глубокому убеждению, если я валидирую JSON со значениями в полях не той длины, не того типа или не того размера, он не должен проходить валидацию по схеме. Однако… все ок, и старушка Альтова валидирует все подряд со всеми типами. Ок… пошел дальше, убрал поля, на которых выставлен атрибут обязательности requaired, нажал f8 и… опять json is valid. Думаю, может я не так подключаю схему? Валидацию я прописываю в Validation against schema и вроде все верно. Может быть я чего-то не знаю о нотации JSON? Был бы благодарен за комментарий.
Добрый день. Вы не забыли указать "$schema": json-schema.org/draft-04/schema# в корне структуры?
Можете привести ваш пример (сложно проанализировать, не видя вашего примера)?
Для валидации можно использовать онлайн-валидаторы, как этот, например: jsonpath.curiousconcept.com, или те, что в статье в списке ссылок приведены.
нет, драфт — 04 не указывал. указал просто "$schema": «json-schema.org/schema#» К сожалению, с драфтом тоже валидирует не все. Начал реагировать на отрицательные значения и на отсутствие обязательных полей. Но к смене типа равнодушен, а это наиболее критично.
Не затруднит привести часть схемы, которая вызывает сложность с учетом корневой структуры? и пример, который по схеме проверяете?
Спасибо за консультации! Все заработало. Джейсон схема действительно находка для решения задач организации моделей данных и определенгия семантики.
Пожалуйста) Рада, что вам нравится результат)
У JSON Schema есть минус, на мой взгляд: схему для данных не удобно писать руками.
Гораздо быстрее и понятнее написать JSON примеры, а из них уже сгенерировать схему.
Причем, если добавить еще какой-нибудь «side-car язызок» к примерам, то генерировать схему из примеров можно 1 к 1, скорей всего (тем более, если допустить, что примеров для генерации схемы может быть несколько).
Что вы об этом думаете? Не знаете ли тулзов, которые это умеют?
С проблемой формулировки модели данных, для которой JSON подходит обычно идеально, встречаются 100% разработчиков. Поэтому и подобного рода тулза была бы крайне востребована.

Добрый день.
По примеру можно сгенерировать схему, но она будет упрощенная, без ссылочности на другие схемы, в рамках только 1 схемы все.
Т. Е. чтобы использовать все преимущества схемы, нужно пониманить, как ее формировать, в том числе, чтобы избежать дублирования.
Золотой пилюли нет, но при первом формировании схемы я тоже пользуюсь автогенерированием "черновика" схемы, а затем уже разбиваю на несколько схем, оптимизирую.
Все утилиты в статье приведены в самом конце. Присмотритесь к ним, думаю, что-то полезное для себя сможете выбрать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории