php проверка на валидность json
Описание и валидация древовидных структур данных. JSON-Schema
Многие сервисы и приложения (особенно веб-сервисы) принимают древовидные данные. Например, такую форму имеют данные, поступающие через JSON-PRC, JSON-REST, PHP-GET/POST. Естественно, появляется задача валидировать их структуру. Существует много вариантов решения этой задачи, начиная от нагромождения if-ов в контроллерах и заканчивая классами, реализующими валидацию по разнообразным конфигурациям. Чаще всего для решения этой задачи требуется рекурсивный валидатор, работающий со схемами данных, описанными по определённому стандарту. Одним из таких стандартов является JSON-Schema, рассмотрим его поближе.
JSON-schema — это стандарт описания структур данных в формате JSON, разрабатываемый на основе XML-Schema, драфт можно найти здесь (далее описанное будет соответствовать версии 03). Схемы, описанные этим стандартом, имеют MIME «application/schema+json». Стандарт удобен для использования при валидации и документировании структур данных, состоящих из чисел, строк, массивов и структур типа ключ-значение (которые, в зависимости от языка программирования, могут называться: объект, словарь, хэш-таблица, ассоциативный массив или карта, далее будет использоваться название «объект» или «object»). На данный момент имеются полные и частичные реализации для разных платформ и языков, в частности javascript, php, ruby, python, java.
Схема
Примеры
Допустим, есть информация о товарах. У каждого товара есть имя. Это строка от 3 до 50 символов, без пробелов на концах. Определим схему для имени товара:
Отлично, теперь этой схемой можно описывать или валидировать любую строку на соответствие имени товара. Далее, у товара есть неотицательная цена, тип (‘phone’ или ‘notebook’), и поддержка wi-fi n и g. Определим схему для товара:
В данной схеме используется ссылка на предыдущую схему и расширение её правилом required. Этого нельзя делать в предыдущей схеме, потому что где-нибудь имя может быть необязательным, а все правила будут применяться.
Производительность
Результаты для 1000 проверок вполне удовлетворительные.
(при этом некоторые библиотеки заявляют на порядок большую скорость).
На моем ноутбуке (MBA, OSX, 1.86 GHz Core2Duo):
names validation: 180ms
products validation: 743ms
Php проверка на валидность json
The JSON Formatter was created to help folks with debugging. As JSON data is often output without line breaks to save space, it can be extremely difficult to actually read and make sense of it. This tool hoped to solve the problem by formatting and beautifying the JSON data so that it is easy to read and debug by human beings.
To further expand the debugging capabilities, advanced JSON validation was soon added following the description set out by Douglas Crockford of json.org in RFC 4627. It has since been updated to allow validation of multiple JSON standards, including both current specifications RFC 8259 and ECMA-404.
Most recently, the capability to fix common JSON errors was added. If enabled, it will replace incorrect quotes, add missing quotes, correct numeric keys, lowercase literals, escape unescaped characters, and remove comments and trailing commas.
Learn About JSON
JSON or JavaScript Object Notation is a language-independent open data format that uses human-readable text to express data objects consisting of attribute-value pairs.
Although originally derived from the JavaScript scripting language, JSON data can be generated and parsed with a wide variety of programming languages including JavaScript, PHP, Python, Ruby, and Java.
To learn more about JSON check out some of the following links.
Bookmarklet
Install the JSON Formatter & Validator Bookmarklet to quickly and easily format and validate any public JSON URL with a single click.
To install, just drag the button above into your bookmarks toolbar.
Have questions? These are the answers to the questions we are most frequently asked.
Can I pass my JSON data in the URL?
Yes! You can populate and process your JSON data automatically by submitting a GET or POST request ( example) with the following query parameters:
When in doubt, our recommendation is to validate JSON with the latest specification, RFC 8259, as it will ensure the highest level of compatibility.
Is any of my JSON data recorded or saved?
Absolutely not! Your data is merely processed and returned directly to you. For more information visit our Privacy Policy.
Is the JSON Formatter & Validator available offline?
In order to keep focused on providing the best JSON beautifier and validator online, we do not offer an offline version.
Can I donate to the project?
Definitely! Although you are in no way obligated, we genuinely appreciate every contribution we receive.
A big thank you goes out to all the donors who have already contributed. We are humbled by your kindness and generosity.
JSON Schema и ее использование для валидация JSON-документов в C++
В данной статье описывается стандарт JSON Schema и его использование для проверки соответствия заданному формату на языке C++ средствами библиотеки valijson.
Немного истории
Для начала вспомним, что привело к повсеместному вытеснению JSON-ом XML-а и что в этом было плохого. XML изначально создавался как метаязык разметки документов, позволяя использовать унифицированный код парсера и валидатора документов. Будучи первым стандартом такого рода, да еще и пришедшимся на период бурного внедрения цифровых корпоративных информационных систем, XML послужил основой для бесчисленного множества стандартов сериализации данных и протоколов взаимодействия, т.е. хранения и передачи структурированных данных. Тогда как создавался он прежде всего для разметки документов.
Будучи разрабатываемым комитетами, стандарт XML оказался дополнен множеством расширений, позволяющих, в частности, избегать конфликтов имен и выполнять сложные запросы в XML-документах. И, самое важное, поскольку получающееся нагромождение тэгов оказывалось совершенно нечитаемым никаким человеком, был разработан и широко реализован стандарт XML Schema, позволяющий на том же XML абсолютно строго описать допустимое содержимое каждого документа с целью последующей автоматической проверки.
Тем временем, все больше разработчиков под влиянием зарождающихся интерактивных web-технологий стало знакомиться с языком JavaScript, и они начали осознавать, что для представления структурированных объектов в текстовом виде совершенно не обязательно изучать много сотен страниц XML-спецификаций. И когда Дуглас Крокфорд предложил стандартизовать подмножество JavaScript для сериализации объектов (но не разметки документов!) безотносительно к языку, идея была поддержана сообществом. В настоящее время JSON является одним из двух (вместе с XML) языков, поддерживаемых всеми сколько-либо популярными технологиями программирования. Тот же YAML, призванный сделать JSON более удобным и человекочитаемым, ввиду своей сложности (т.е. широты возможностей) распространен не так широко (в моей компании не так давно были проблемы с работой с YAML из MATLAB, тогда как с JSON все хорошо).
Так вот, массово начав использовать JSON для представления данных, разработчики столкнулись с необходимостью вручную проверять содержимое документов, каждый раз на каждом языке переизобретая логику валидации. Людей, знакомых с XML Schema, это не могло не бесить. И постепенно аналогичный стандарт JSON Schema таки сформировался и живет по адресу http://json-schema.org/.
JSON Schema
Рассмотрим пример простой, но показательной, схемы, задающей словарь 2D или 3D геометрических точек в пространстве (-1, 1)x(-1, 1)x(-1, 1) с ключами, состоящими из цифр:
Но это в том случае, если для вашего языка/платформы реализован валидатор. В случае с XML такой вопрос вряд ли мог бы встать.
На http://json-schema.org/ сайте вы можете найти список ПО для валидации. И вот в этом месте незрелость JSON-Schema (и ее сайта) дает о себе знать. Для C++ указана одна (вроде бы интересная) библиотека libvariant, которая занимается валидацией лишь по совместительству и к тому же выпущена под зловредной лицензией LGPL (прощай, iOS). Для C у нас тоже один вариант, и тоже под LGPL.
Тем не менее, приемлемое решение существует и называется valijson. У этой библиотеки есть все что нам нужно (валидация схем и BSD-лицензия), и даже больше, — независимость от JSON-парсера. Valijson позволяет использовать любой json-парсер посредством адаптера (в комплекте адаптеры для jsoncpp, json11, rapidjson, picojson и boost::property_tree), таким образом не требуя переходить на новую json-библиотеку (или тащить за собой еще одну). Плюс ко всему, она состоит только из заголовочных файлов (header only) и не требует компиляции. Очевидный минус только один, и то не для всех, — зависимость от boost. Хотя есть надежда на избавление даже от этого недо-недостатка.
Разберем на примере документа составление JSON-схемы и валидацию этого документа.
Пример составления схемы
Допустим, у нас есть таблица неких полосатых объектов, для которых задана конкретная полосатая раскраска (в виде последовательности 0 и 1, соответствующих черному и белому).
Здесь мы имеем словарь с числовыми ключами, к которым может быть приписан суффикс «inv» (для инвертированных штрих-кодов). Все значения в словаре являются объектами и обязаны иметь поля «width», «stripe_length» (строго положительные числа) и «code» (строка нулей и единиц длины 12).
Начнем составлять схему, указав ограничения на формат имен полей верхнего уровня:
Здесь мы воспользовались конструктом patternProperties, разрешающим/специфицирующим значения, ключи которых удовлетворяют регулярному выражению. Также мы указали (additionalProperties=false), что неспецифицированные ключи запрещены. Используя additionalProperties, можно не только разрешить или запретить неуказанные явно поля, но и наложить ограничения на их значения, указав в качестве значения спецификатор типа, например, так:
Далее опишем тип значения каждого объекта в словаре:
Здесь мы явно перечисляем разрешенные поля (properties), требуя их наличие (required), не запрещая (по умолчанию) любые дополнительные свойства. Числовые свойства у нас строго положительные, а строка code должна соответствовать регулярному выражению.
В принципе осталось только вставить описание типа отдельного объекта в вышеописанную схему таблицы. Но прежде чем это сделать, отметим, что у нас дублируется спецификация полей «width» и «stripe_length». В реальном коде, из которого взят пример, таких полей еще больше, поэтому полезно было бы один раз определить данный тип, а потомы ссылаться на него отосвюду. Именно для этого есть механизм ссылок ($ref). Обратите внимание на секцию definitions в итоговой схеме:
Сохраним ее в файл и приступим к написанию валидатора.
Применение valijson
В качестве json-парсера используем jsoncpp. Имеем обычную функцию загрузки json-документа из файла:
Минимальная функция-валидатор, сообщающая нам о расположении всех ошибок валидации, выглядит примерно так:
Теперь мы можем загружать и валидировать документы:
Все, мы научились валидировать json-документы. Но обратим внимание, что теперь нам придется думать, где хранить схемы! Ведь если документ каждый раз меняется и получается, например, из web-запроса или из аргумента командной строки, то схема неизменна и должна поставляться вместе с приложением. А для небольших программ без развитого механизма загрузки статических ресурсов необходимость введения такового представляет значительный барьер для внедрения валидачии через схемы. Вот было бы здорово компилировать схему вместе с программой, ведь изменение схемы в любом случае потребует изменения кода, обрабатывающего документ.
Это возможно и даже довольно удобно, если в нашем распоряжении есть C++11. Решение примитивное, но работает прекрасно: мы просто определяем строковую константу с нашей схемой. А чтоб не заботиться о кавычках внутри строки, мы используем raw string literal:
Решение типовых проблем с json_encode (PHP)
Это краткая статья о наиболее вероятных проблемах с json_encode и их решениях. Иногда при кодировании данных в json, с помощью json_encode в php, мы получаем не тот результат который ожидаем. Я выделил три наиболее частые проблемы с которыми сталкиваются программисты:
Доступ к полям
Проблема заключается в том что json_encode имеет доступ только к публичным полям объекта. Например если у вас есть класс
то результатом выполнения следующего кода будет:
как видно в результирующий json были включены только публичные поля.
Что же делать если нужны все поля?
Решение
Для php = 5.4:
достаточно будет реализовать интерфейс JsonSerializable для нашего класса, что подразумевает добавление метода jsonSerialize который будет возвращать структуру представляющую объект для json_encode
Теперь мы можем использовать json_encode как и раньше
Почему не стоит использовать подход с toJson методом?
Многие наверно заметили что подход с созданием метода возвращающего json может быть использован и в версиях php >= 5.4. Так почему же не воспользоваться им? Все дело в том что ваш класс может быть использован как часть иной структуры данных
и результат уже будет совсем другой.
Также класс может использоваться другими программистами, для которых такой тип получение json-а с объекта может быть не совсем очевиден.
Что если у меня очень много полей в класcе?
В таком случае можно воспользоваться функцией get_object_vars
А если нужно private-поля, из класса, который нет возможности редактировать?
Может получиться ситуация когда нужно получить private поля (именно private, т.к. доступ к protected полям можно получить через наследование) в json-е. В таком случае необходимо будет воспользоваться рефлексией:
Кодировка текстовых значений
Кириллица и другие знаки в UTF8
Второй тип распространённых проблем с json_encode это проблемы с кодировкой. Часто текстовые значения которые нужно кодировать в json имеют в себе символы в UTF8 (в том числе кириллица) в результате эти символы будут представлены в виде кодов:
Отображение таких символов лечится очень просто — добавлением флага JSON_UNESCAPED_UNICODE вторым аргументом к функции json_encode:
Символы в других кодировках
Функция json_encode воспринимает строковые значения как строки в UTF8, что может вызвать ошибку, если кодировка другая. Рассмотрим маленький кусочек кода (данный пример кода максимально упрощен для демонстрации проблемной ситуации)
На первый взгляд ничего не предвещает проблем, да и что здесь может пойти не так? Я тоже так думал. В подавляющем большинстве случаев все будет работать, и по этой причине поиск проблемы занял у меня несколько больше времени, когда я впервые столкнулся с тем что результатом json_encode было false.
Как можно увидеть из ошибки: проблема с кодировкой переданной строки (это не UTF8). Решение проблемы очевидное — привести значение в UTF8
Цифровые значения
Последняя типовая ошибка связана с кодированием числовых значений.
Как известно php не строго типизированный язык и позволяет использовать числа в виде строки, в большинстве случаев это не приводит к ошибкам внутри php приложения. Но так как json очень часто используется для передачи сообщений между приложениями, такой формат записи числа может вызвать проблемы в другом приложении. Желательно использовать флаг JSON_NUMERIC_CHECK:
Уже лучше. Но как видим «3.0» превратилось в 3, что в большинстве случаев будет интерпретировано как int. Используем еще один флаг JSON_PRESERVE_ZERO_FRACTION для корректного преобразования в float:
Прошу также обратить внимание на следующий фрагмент кода, что иллюстрирует ряд возможных проблем с json_encode и числовыми значениями:
Спасибо за прочтение.
Буду рад увидеть в комментариях описание проблем, с которыми вы сталкивались, что не были упомянуты в статье
Проверка данных с помощью JSON-схемы, часть 1
Когда вы имеете дело со сложными и структурированными данными, вам необходимо определить, являются ли данные действительными или нет. JSON-схема — это стандарт документов JSON, который описывает структуру и требования к вашим данным JSON. В этой серии из двух частей вы узнаете, как использовать JSON-схему для проверки данных.
Допустим, у вас есть база данных пользователей, где каждая запись выглядит примерно так:
Вопрос, с которым мы собираемся разобраться, заключается в том, как определить, является ли запись, подобная приведенной выше, действительной или нет.
Примеры очень полезны, но недостаточны при описании ваших требований к данным. На помощь приходит JSON-схема. Это одна из возможных схем, описывающих запись пользователя:
Посмотрите на схему выше и запись пользователя, которую она описывает (которая действительна в соответствии с этой схемой). Здесь есть много объяснений.
Код JavaScript для проверки записи пользователя по схеме может быть:
или для лучшей производительности: javascript var validate = ajv.compile(userSchema); var valid = validate(userData); if (!valid) console.log(validate.errors); javascript var validate = ajv.compile(userSchema); var valid = validate(userData); if (!valid) console.log(validate.errors);
Прежде чем мы продолжим, давайте быстро разберемся со всеми причинами.
Зачем проверять данные как отдельный шаг?
Почему JSON (а не XML)?
Зачем использовать схемы?
Почему JSON-схема?
Задания
Этот учебник включает в себя несколько относительно простых задач, которые помогут вам лучше понять схему JSON и то, как ее можно использовать. Есть простые сценарии JavaScript, чтобы проверить, что вы сделали их правильно. Для их запуска вам нужно установить node.js (вам не нужно с этим работать). Просто установите nvm (менеджер версий узлов) и последнюю версию node.js:
Вам также необходимо клонировать репозиторий и запустить npm install (он установит валидатор Ajv).
Давайте погрузимся в схемы!
JSON-схема всегда является объектом. Его свойства называются «ключевые слова». Некоторые из них описывают правила для данных (например, «тип» и «свойства»), а некоторые описывают саму схему («$ schema», «id», «title», «description») — мы перейдем к их позже.
Данные действительны в соответствии со схемой, если они действительны для всех ключевых слов в этой схеме — это действительно просто.
Свойства данных
В приведенном выше примере вы могли заметить, что каждое свойство внутри ключевого слова «properties» описывает соответствующее свойство в ваших данных.
Здесь важно то, что ключевое слово «properties» не требует никаких свойств; он определяет только схемы для свойств, присутствующих в данных.
Например, если наша схема:
тогда объекты со свойством «foo» или без него могут быть действительными согласно этой схеме:
и только объекты, которые имеют свойство foo, не являющееся строкой, недопустимы:
Тип данных
Как видно из приведенного выше примера, пользовательские данные должны быть объектом.
Большинство ключевых слов применяются к определенным типам данных — например, ключевое слово «свойства» применяется только к объектам, а ключевое слово «шаблон» применяется только к строкам.
Что значит «подать заявку»? Допустим, у нас действительно простая схема:
Вы можете ожидать, что, чтобы быть действительным согласно такой схеме, данные должны быть строкой, соответствующей шаблону:
Но стандарт JSON-схемы указывает, что если ключевое слово не относится к типу данных, то данные действительны в соответствии с этим ключевым словом. Это означает, что любые данные, не относящиеся к типу «строка», действительны в соответствии с приведенной выше схемой — числа, массивы, объекты, логические значения и даже ноль. Если вы хотите, чтобы действительными были только строки, соответствующие шаблону, ваша схема должна быть:
Благодаря этому вы можете создавать очень гибкие схемы, которые будут проверять несколько типов данных.
Посмотрите на свойство «id» в примере пользователя. Он должен быть действительным в соответствии с этой схемой:
Другой, более подробный способ выразить то же самое требование:
Но из-за способа определения JSON-схемы эта схема эквивалентна первой, которая короче и быстрее проверяется в большинстве валидаторов.
Проверка номеров
Есть несколько ключевых слов для проверки чисел. Все ключевые слова в этом разделе относятся только к числам (включая целые числа).
тогда эта схема потребовала бы, чтобы возраст пользователя был строго больше 13, то есть минимально допустимый возраст был бы 14.
Проверка строк
Есть также несколько ключевых слов для проверки строк. Все ключевые слова в этом разделе относятся только к строкам.
Некоторые валидаторы определяют длины строк в соответствии со стандартом, а некоторые делают это способом JavaScript, что быстрее. Ajv позволяет вам указать, как определять длину строки, и по умолчанию это соответствует стандарту.
Вы уже видели ключевое слово «pattern» в действии — оно просто требует, чтобы строка данных соответствовала регулярному выражению, определенному в соответствии с тем же стандартом, который используется в JavaScript. Смотрите пример ниже для схем и соответствующих регулярных выражений:
Большинство валидаторов позволяют вам определять пользовательские форматы как регулярные выражения или проверочные функции. Мы могли бы определить собственный формат «телефон» для нашей схемы, чтобы использовать его в нескольких местах:
и тогда схема для свойства phone будет такой:
Задание 1
Создайте схему, которая потребует, чтобы данные были датой (строка) или годом (числом), а год был больше или равен 1976 году.
Поместите свой ответ в файл part1/task1/date_schema.json и запустите node part1/task1/validate чтобы проверить его.
Проверка объекта
В дополнение к «свойствам» в нашем примере пользователя вы можете увидеть несколько других ключевых слов, которые применяются к объектам.
Если бы у нас была эта схема:
тогда все объекты без свойства foo будут недействительными.
Ключевое слово «patternProperties» позволяет вам определять схемы, в соответствии с которыми значение свойства данных должно быть допустимым, если имя свойства соответствует регулярному выражению. Его можно комбинировать с ключевым словом «properties» в той же схеме.
Свойство feeds в пользовательском примере должно быть допустимым в соответствии с этой схемой:
Чтобы быть действительными, feeds должны быть объектом со свойствами, имена которых состоят только из латинских букв и значения которых являются логическими.
Ключевое слово «AdditionalProperties» позволяет вам либо определить схему, в соответствии с которой все остальные ключевые слова (не используемые в «свойствах» и не соответствующие «patternProperties» ) должны быть действительными, либо полностью запретить другие свойства, как мы это делали в свойстве feeds схема выше.
В следующем примере «AdditionalProperties» используется для создания простой схемы для хеша целых чисел в определенном диапазоне:
Ключевые слова «maxProperties» и «minProperties» позволяют ограничить количество свойств в объекте. В нашем пользовательском примере схема для свойства address выглядит следующим образом:
Существует два типа таких требований к объекту: иметь некоторые другие свойства (это называется «зависимость от свойства») или удовлетворить некоторую схему («зависимость от схемы»).
В нашем пользовательском примере одна из возможных схем, в отношении которых пользовательское соединение должно быть действительным, заключается в следующем:
Для этого требуется, connType свойство connType равно «относительному» (см. Ключевое слово «enum» ниже), а если свойство relation присутствует, это строка.
Обратите внимание, что схема в свойстве «отношение» в ключевом слове «зависимости» используется для проверки родительского объекта (т. Е. Соединения), а не значения свойства relation в данных.
Задача 2
Ваша база данных содержит людей и машины. Используя только ключевые слова, которые я объяснил до сих пор, создайте схему для проверки обоих. Образец человеческого объекта:
Пример машинного объекта:
Обратите внимание, что это должна быть одна схема для проверки как людей, так и машин, а не две схемы.
Поместите свой ответ в файл part1/task2/human_machine_schema.json и запустите node part1/task2/validate чтобы проверить его.
Подсказки: используйте ключевое слово «зависимости» и посмотрите в файле part1/task2/invalid.json чтобы увидеть, какие объекты должны быть недействительными.
Основным выводом из этой задачи является тот факт, что целью валидации является не только валидация всех действительных объектов как допустимых. Я много раз слышал этот аргумент: «Эта схема проверяет мои действительные данные как действительные, поэтому они верны». Этот аргумент неверен, потому что вам не нужно много делать для его достижения — пустая схема сделает работу, потому что он проверяет достоверность любых данных.
Я думаю, что основная цель проверки состоит в том, чтобы проверить недействительные данные как недействительные, и в этом вся сложность.
Проверка массива
Существует несколько ключевых слов для проверки массивов (и они применяются только к массивам).
«MaxItems» и «minItems» требуют, чтобы массив содержал не больше (или не меньше), чем определенное количество элементов. В примере пользователя схема требует, чтобы количество соединений не превышало 150.
Ключевое слово «items» определяет схему (или схемы), в соответствии с которой элементы должны быть действительными. Если значением этого ключевого слова является объект (как в примере с пользователем), то этот объект является схемой, в соответствии с которой данные должны быть действительными.
Если значением ключевого слова «items» является массив, то этот массив содержит схемы, в соответствии с которыми соответствующие элементы должны быть действительными:
Схема в простом приведенном выше примере требует, чтобы данные представляли собой массив, причем первый элемент является целым числом, а второй — строкой.
Как насчет предметов после этих двух? Схема выше не определяет никаких требований для других предметов. Они могут быть определены с помощью ключевого слова « AdditionalItems».
Если ключевое слово « AdditionalItems» имеет значение true, оно просто игнорируется. Если оно ложно и в данных содержится больше элементов, чем в ключевом слове «items», проверка завершается неудачно:
Если ключевое слово « AdditionalItems» является объектом, то этот объект является схемой, в соответствии с которой все дополнительные элементы должны быть действительными:
Проверка ключевого слова «uniqueItems» может быть вычислительно дорогой, поэтому некоторые валидаторы решили не реализовывать ее или делать это только частично.
Ajv имеет возможность игнорировать это ключевое слово:
Задача 3
Одним из способов создания объекта даты в JavaScript является передача от 2 до 7 чисел в конструктор Date:
У вас есть массив. Создайте схему, которая проверит, что это допустимый список аргументов для конструктора Date.
Поместите свой ответ в файл part1/task3/date_args_schema.json и запустите node part1/task3/validate чтобы проверить его.
Ключевое слово «Enum»
Ключевое слово enum требует, чтобы данные были равны одному из нескольких значений. Это относится ко всем типам данных.
В примере пользователя он используется для определения gender свойства внутри personal свойства как «мужской» или «женский». Он также используется для определения свойства connType в пользовательских подключениях.
Ключевое слово «enum» может использоваться с любыми типами значений, не только со строками и числами, хотя это не очень распространено.
Он также может использоваться для требования, чтобы данные были равны определенному значению, как в примере пользователя:
Предложения для следующей версии (v5) стандарта JSON-Schema включают ключевое слово «константа», чтобы сделать то же самое.
Ajv позволяет использовать «константу» и некоторые другие ключевые слова из v5:
Ключевые слова проверки соединения
Есть несколько ключевых слов, которые позволяют вам определить расширенную логику, включающую проверку по нескольким схемам. Все ключевые слова в этом разделе относятся ко всем типам данных.
В нашем примере пользователя используется ключевое слово «oneOf» для определения требований к пользовательскому соединению. Это ключевое слово допустимо, если данные успешно проверены по одной схеме внутри массива.
Если данные являются недействительными по всем схемам в ключевом слове «oneOf» или действительны по двум или более схемам, то данные являются недействительными.
Давайте посмотрим более внимательно на наш пример:
Приведенная выше схема требует, чтобы пользовательское соединение было либо «относительным» (свойство connType ), и в этом случае оно может иметь свойства relation (строка) и close (логическое), либо один из типов «друг», «коллега» или «другое» ( в этом случае он не должен иметь relation свойств и close ).
Эти схемы для подключения пользователя являются взаимоисключающими, потому что нет данных, которые могли бы удовлетворить их обоих. Поэтому, если соединение допустимо и имеет тип «относительный», нет смысла проверять его по второй схеме — оно всегда будет недействительным. Тем не менее, любой валидатор всегда будет проверять данные по обеим схемам, чтобы убедиться, что они действительны только по одной схеме.
В случаях, подобных описанным выше, когда схемы являются взаимоисключающими и никакие данные не могут быть действительными в соответствии с более чем одной схемой, лучше использовать ключевое слово «anyOf» — оно будет проверяться быстрее в большинстве случаев (кроме той, в которой данные действительны в соответствии с последней схемой).
Использование «oneOf» в тех случаях, когда «anyOf» выполняет одинаково хорошую работу, является очень распространенной ошибкой, которая отрицательно влияет на производительность проверки.
Однако в некоторых случаях нам действительно необходимо ключевое слово «oneOf» :