Валидация JSON во входящих REST-запросах DATAREON Platform

В сфере искусственного интеллекта произошло заметное событие. IlyaVyaznikov 5 минут назад Краткое содержание статьи Валидация JSON во входящих REST-запросах DATAREON Platform Средний 12 мин 4 Блог компании SOFROS Проектирование API * Анализ и проектирование систем * C# * Кейс С вами снова Илья Вязников, инженер сопровождения СОФРОС. Продолжаю делиться практическими приёмами работы с платформой. При интеграции информационных систем через REST API зачастую возникает необходимость проверки входящих данных на соответствие установленным требованиям.

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

Технические детали

Это позволяет централизованно управлять правилами валидации, выявлять ошибки до передачи данных в целевые системы и сокращать необходимость доработок в прикладном ПО. Для ЛЛ Спойлер: что выяснилось на тестахПри тестировании кейса выяснилась интересная особенность: DATAREON Platform может отклонить запрос ещё до выполнения пользовательского кода валидации. В таком случае отправитель получит информацию об ошибках типов данных, но нарушения бизнес-правил будут обнаружены только после их исправления.

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

Поля типа данных объявляем с настоящими типами (String, DateTime, Decimal, Int), платформа сама отклоняет значения не того типа. Формат кода товара, диапазоны, обязательность - всё, что типом не выразить, проверяем в коде веб-обработчика. Ошибки обоих уровней клиент получает в одном и том же JSON-формате благодаря настройке responseErrorSettings.

Отраслевые последствия

Например:{ "errorCode": 400, "errorMessage": "данные не прошли проверку", "notValidFields": "meta. code" }Корректное сообщение получает HTTP 200 и уходит в Platform на дальнейшую обработку. Все примеры ниже проверены на стенде DATAREON Platform 3.

СценарийПредставим простой интеграционный сценарий: складская система принимает новую партию и передаёт в DATAREON Platform пакет данных о регистрации товара. Дальше эти данные уходят в учётную систему, где дата должна быть датой, цена - числом, а код товара - в формате справочника. В meta содержатся сведения об источнике и документе, а в массиве items - передаваемые товарные позиции:{ "meta": { "source": "warehouse", "document_type": "product", "created_at": "2026-10-21" }, "items": [ { "name": "Товар 1", "code": " 001", "price": 1500.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.