ChatGPT API: проверка JSON перед действием

Определите контракт для одной операции

Начните не с универсальной схемы, а с одного понятного результата. Например, помощник может предложить черновик ответа с полями title, summary и confidence. Зафиксируйте допустимые типы, максимальную длину, список разрешённых значений и состояние, в котором результат можно показать. Поле action само по себе не должно давать право менять CRM, отправлять письмо или списывать деньги. Сервер связывает предложение с текущим пользователем, проектом и локальной операцией, а интерфейс показывает его как черновик. Такой контракт упрощает тестирование: неизвестное поле, неверный enum или слишком длинная строка дают предсказуемый validation_error, а не неявное преобразование.

Проверяйте форму после получения ответа

Даже если клиент просил структурированный ответ, валидируйте данные после получения и до рендеринга. Модель, адаптер или версия SDK могут вернуть пустую строку, объект другой формы или JSON внутри Markdown. Ограничьте размер полезной нагрузки, извлеките только ожидаемый объект и пропустите его через схему на сервере. Не исправляйте произвольный JSON догадками: если обязательного поля нет, сохраните безопасную диагностическую причину и предложите повторить запрос либо передать его на review. В журнал достаточно записать request ID, имя схемы, версию приложения и результат проверки; пользовательский текст и заголовки авторизации туда не попадают.

Отбрасывайте неизвестные поля и опасные значения

Allowlist защищает не только от опечаток. Неизвестное поле может выглядеть безобидно, но оказаться попыткой изменить роль, project ID, URL перенаправления или внутренний флаг интерфейса. После успешной проверки создавайте новый объект из разрешённых значений, а не передавайте исходный ответ дальше по приложению. Для ссылок проверяйте схему URL и разрешённые домены, для чисел — диапазон, для идентификаторов — принадлежность текущему проекту. HTML не вставляйте как готовую разметку: рендерите обычный текст либо очищайте его специализированным механизмом. Такая проверка не делает ответ фактом; она лишь гарантирует, что приложение обработало допустимую форму.

Разделите генерацию, подтверждение и побочный эффект

Модель может предложить классификацию или текст, но окончательное действие проходит отдельные серверные шаги. Создайте локальную операцию со статусом proposed, покажите человеку понятное содержание и потребуйте явного подтверждения, если операция меняет данные, отправляет сообщение или влияет на деньги. При подтверждении сервер ещё раз читает проект, права пользователя и актуальное состояние объекта. Используйте idempotency key, чтобы двойной клик или повтор сети не выполнили действие дважды. Если результат устарел, конфликтует с текущей записью или требует более высоких прав, остановите его со статусом review_required. Не поручайте модели выдавать разрешения и не считайте одно согласие вечным.

Постройте отрицательные тесты и наблюдаемость

Надёжность схемы проверяют не только примеры успеха. Добавьте fixtures с лишним полем, неверным типом, пустым объектом, слишком длинной строкой, неверным tenant и повторным подтверждением. Для каждого случая определите локальный статус и ожидаемое сообщение без деталей внутренней policy. В метриках считайте долю valid, rejected, review_required и expired по версии схемы, не записывая значения полей. Связывайте запись с собственным operation ID и request ID транспорта, если он доступен. Рост отклонений после изменения SDK — повод остановить rollout и сравнить нормализованные ответы на обезличенном наборе, а не ослабить правила ради быстрого ответа.

Обновляйте контракт контролируемо

Версия схемы должна жить рядом с кодом и тестами. При добавлении поля сначала сделайте его необязательным в новой версии, измерьте обработку и только затем используйте в критическом сценарии. При удалении поля оставьте период совместимости, если старые клиенты ещё могут отправить подтверждение. Перед выпуском прогоните server-side smoke test в отдельном окружении и назначьте владельца rollback. Документация конкретного gateway, каталог и договор могут меняться; поэтому не делайте из статьи обещание постоянной JSON-совместимости. Ценность подхода в том, что изменение становится наблюдаемым и безопасно останавливаемым на стороне вашего приложения.

Server-side пример

Пример рассчитан на Node.js 18+ и защищённый server-side запуск. Он не содержит реального ключа и показывает логику приложения; перед интеграцией подтвердите текущую схему, маршрут и ограничения в документации.

function validateDraft(input) {
  if (!input || typeof input !== 'object' || Array.isArray(input)) return { ok: false, reason: 'not_object' };
  const allowed = ['title', 'summary', 'confidence'];
  if (Object.keys(input).some(key => !allowed.includes(key))) return { ok: false, reason: 'unknown_field' };
  if (typeof input.title !== 'string' || input.title.length < 1 || input.title.length > 120) return { ok: false, reason: 'bad_title' };
  if (typeof input.summary !== 'string' || input.summary.length > 1000) return { ok: false, reason: 'bad_summary' };
  if (!Number.isInteger(input.confidence) || input.confidence < 0 || input.confidence > 100) return { ok: false, reason: 'bad_confidence' };
  return { ok: true, value: { title: input.title, summary: input.summary, confidence: input.confidence } };
}
// Run server-side. Validate current provider fields and your business policy separately.

Проверьте синтаксис через node --check, добавьте аутентификацию, лимиты и отрицательные тесты. Не записывайте в журнал тело запроса целиком или заголовки авторизации.

Перед production выполните тест в отдельном environment, назначьте владельца проверки и зафиксируйте результат без чувствительных данных. Повторяйте проверку при смене версии клиента, модели или серверной policy.

Граница ответственности

Это руководство описывает защитные механизмы вашего приложения, а не гарантии конкретного провайдера или модели. Не передавайте в браузер, статьи, тикеты или логи API-ключи, заголовки Authorization, cookie, исходные ключи поставщиков либо полные пользовательские данные.

Материалы для сверки

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

• OWASP: проверка входных данных
• RFC 8259: формат JSON