Валидатор контракта API-ответа

Проверяет реальный JSON-ответ API на соответствие response schema из OpenAPI 3.x

Вставьте документ OpenAPI 3.x и реальный ответ API, затем укажите path, method и status code. Инструмент найдет нужную response schema и покажет отсутствующие поля, ошибки типов, нарушения enum и недокументированные поля.

Как использовать:

  • Спецификация OpenAPI: вставьте YAML или JSON
  • JSON ответа: вставьте реальный payload
  • Путь / Метод / Код статуса: выберите операцию и ветку ответа
  • Формат спецификации: используйте auto, если формат неизвестен
  • Запретить лишние поля: предупреждать о полях вне схемы

Примеры результатов

1 Примеры

Проверить, соответствует ли реальный ответ схеме пользователя

Сравнивает реальный JSON с контрактом OpenAPI и находит пропуски и расхождения типов.

Contract validation issues
Показать параметры ввода
{ "openApiSpec": "openapi: 3.0.3\npaths:\n /users/{id}:\n get:\n responses:\n \"200\":\n description: ok\n content:\n application/json:\n schema:\n type: object\n required: [id, name]\n properties:\n id: { type: integer }\n name: { type: string }\n active: { type: boolean }", "responseJson": "{\"id\":\"1\",\"active\":\"yes\"}", "path": "/users/42", "method": "get", "statusCode": "200", "specFormat": "yaml", "disallowAdditionalProperties": true }

Ключевые факты

Категория
Разработка и Web
Типы входных данных
textarea, text, select, checkbox
Тип результата
html
Покрытие примерами
4
API доступен
Yes

Обзор

Валидатор контракта API-ответа — это инструмент для быстрой проверки реальных JSON-ответов на соответствие схемам, описанным в спецификации OpenAPI 3.x. Он автоматически находит нужную схему по указанному пути, методу и HTTP-статусу, а затем выявляет пропущенные обязательные поля, несовпадения типов данных, нарушения перечислений (enum) и незадокументированные свойства. Это помогает разработчикам и тестировщикам гарантировать, что API строго соблюдает заявленный контракт.

Когда использовать

  • •При отладке новых эндпоинтов API для проверки корректности формируемого JSON-ответа.
  • •Во время интеграционного тестирования для выявления нарушений контракта между клиентом и сервером.
  • •При обновлении спецификации OpenAPI, чтобы убедиться, что текущая реализация API соответствует новым требованиям.

Как это работает

  • •Вставьте вашу спецификацию OpenAPI 3.x (в формате YAML или JSON) и реальный JSON-ответ от сервера.
  • •Укажите путь (например, /users/123), HTTP-метод и код статуса (например, 200), чтобы инструмент нашел соответствующую схему.
  • •Включите опцию «Запретить лишние поля», если хотите получать предупреждения о свойствах, не описанных в документации.
  • •Инструмент проанализирует данные и выведет подробный HTML-отчет с указанием всех расхождений и ошибок валидации.

Сценарии использования

Проверка ответов микросервисов перед релизом для предотвращения поломок на стороне клиентских приложений.
Валидация мок-данных (mock data) на соответствие утвержденному контракту OpenAPI на этапе проектирования.
Поиск причин ошибок парсинга на фронтенде путем сравнения реального ответа бэкенда с ожидаемой схемой.

Примеры

1. Проверка ответа профиля пользователя

Backend-разработчик
Контекст
Разработчик добавил новое поле в ответ API профиля пользователя, но забыл обновить спецификацию.
Проблема
Убедиться, что реальный ответ API полностью соответствует заявленному контракту OpenAPI.
Как использовать
Вставить YAML-спецификацию и JSON-ответ, указать путь /users/42, метод GET и статус 200, включив запрет лишних полей.
Результат
Инструмент подсвечивает новое поле как незадокументированное, напоминая разработчику обновить OpenAPI-файл.

2. Отладка ошибки типа данных

QA-инженер
Контекст
Мобильное приложение падает при получении списка товаров из-за неожиданного формата данных.
Проблема
Найти расхождение между ожидаемым типом данных в контракте и реальным ответом сервера.
Как использовать
Загрузить спецификацию и проблемный JSON-ответ, выбрать метод GET и статус 200 для пути /products.
Результат
Валидатор показывает, что поле price возвращается как строка, хотя в схеме OpenAPI оно описано как число (integer).

Проверить на примерах

json
Postman Collections - API Тестирование
Всесторонние примеры Postman collections включая API тестирование, скрипты автоматизации, переменные окружения, mock серверы и продвинутые паттерны тестирования для REST API
title token api
json
Примеры AWS EventBridge
Примеры AWS EventBridge включая шины событий, правила, цели, реестр схем, пользовательские события и межаккаунтную маршрутизацию событий для бессерверной событийно-ориентированной архитектуры
preferred input family json
json
Примеры Apache Pulsar
Примеры Apache Pulsar включая pub/sub, ридеры, потребители с разными типами подписок, управление схемами и многоуровневое хранилище для корпоративной обмена сообщениями
preferred input family json
json
Примеры OpenAPI/Swagger
Комплексные примеры документации API с использованием OpenAPI 3.0 и спецификаций Swagger для RESTful сервисов
preferred input family json
json

Связанные хабы

Инструменты Json для Validate
Изучите 7 инструментов json для сценариев validate и быстро сравните близкие утилиты.
Инструменты Json для Convert
Изучите 100 инструментов json для сценариев convert и быстро сравните близкие утилиты.
Инструменты Json
Изучите 45 инструментов json для сценариев utility и быстро сравните близкие утилиты.
Инструменты Json для Generate
Изучите 33 инструментов json для сценариев generate и быстро сравните близкие утилиты.

FAQ

Поддерживает ли инструмент OpenAPI версии 2.0 (Swagger)?

Нет, инструмент предназначен исключительно для работы со спецификациями формата OpenAPI 3.x.

Нужно ли вручную указывать формат спецификации?

По умолчанию используется режим «Auto», который автоматически определяет формат (YAML или JSON). Вы можете задать его вручную, если автоопределение не сработало.

Что делает опция «Запретить лишние поля»?

Она включает строгую проверку, помечая любые поля в JSON-ответе, которых нет в схеме OpenAPI, как ошибки валидации.

Как правильно указать путь для проверки?

Укажите реальный путь запроса (например, /users/42) или шаблон из спецификации. Инструмент сопоставит его с доступными путями (например, /users/{id}).

Какие именно ошибки находит валидатор?

Валидатор обнаруживает отсутствие обязательных полей, неверные типы данных (например, строка вместо числа), выход за пределы допустимых значений (enum) и наличие незадокументированных полей.

Документация API

Конечная точка запроса

POST /ru/api/tools/api-response-contract-validator

Параметры запроса

Имя параметра Тип Обязательно Описание
openApiSpec textarea Да -
responseJson textarea Да -
path text Да -
method select Нет -
statusCode text Да -
specFormat select Нет -
disallowAdditionalProperties checkbox Нет -

Формат ответа

{
  "result": "
Processed HTML content
",
  "error": "Error message (optional)",
  "message": "Notification message (optional)",
  "metadata": {
    "key": "value"
  }
}
HTML: HTML

Документация MCP

Добавьте этот инструмент к конфигурации сервера MCP: 

{
  "mcpServers": {
    "elysiatools-api-response-contract-validator": {
      "name": "api-response-contract-validator",
      "description": "Проверяет реальный JSON-ответ API на соответствие response schema из OpenAPI 3.x",
      "baseUrl": "https://elysiatools.com/mcp/sse?toolId=api-response-contract-validator",
      "command": "",
      "args": [],
      "env": {},
      "isActive": true,
      "type": "sse"
    }
  }
}

Вы можете объединять несколько инструментов, например: `https://elysiatools.com/mcp/sse?toolId=png-to-webp,jpg-to-webp,gif-to-webp`, максимум 20 инструментов.

Если вы столкнулись с проблемами, пожалуйста, свяжитесь с нами по адресу [email protected]