Что такое problem+json и зачем он нужен?

Это формат ошибок, стандартизованный в RFC 9457: небольшой согласованный набор полей, чтобы клиенты и логи читали ошибки любого API одинаково, вместо того чтобы каждый сервис выдумывал собственную обёртку.

Почему status есть и в теле, и в ответе?

Поле status в теле дублирует HTTP-статус, чтобы залогированный или переданный дальше документ оставался осмысленным в отрыве от ответа. RFC 9457 требует, чтобы они совпадали, и расхождение — это баг, на который стоит завести проверку.

Массив errors — часть стандарта?

Нет. RFC 9457 разрешает поля-расширения, и errors — одно из них: детализация по полям, которую обычно добавляют API в стиле GitHub или Stripe. Клиенту стоит считать стандартные поля гарантированными, а расширения — необязательными.

Замокать ошибку problem+json по RFC 9457

GET-мок, который отдаёт 422 application/problem+json с ошибкой валидации в формате RFC 9457.

RFC 9457 описывает application/problem+json — стандартную форму тела HTTP-ошибки с полями type, title, status и detail. Шаблон отдаёт problem-документ со статусом 422 и расширением с ошибками по полям, чтобы обработку ошибок можно было строить и проверять против формата, а не против того произвольного JSON, который ваш бэкенд отдаёт сегодня.

Заменяет собой эндпоинт стороннего API.

Тело ответа

{"type":"https://quickmock.dev/problems/validation-error","title":"Your request parameters didn't validate","status":422,"detail":"The 'email' field must be a valid email address.","instance":"{{mock.url}}/requests/38f0","errors":[{"field":"email","message":"must be a valid email address"}]}

Поля, на которые стоит обратить внимание

Поле	Что означает
type	URI, идентифицирующий тип проблемы — это адрес документации, а не обязательно рабочая ссылка.
title	Короткое человекочитаемое описание проблемы.
status	Дублирует статус HTTP-ответа в теле — для клиентов, которые логируют его отдельно.
detail	Конкретное объяснение для этого случая; поправьте под сбой, который вы тестируете.
errors	Нестандартное расширение с ошибками по полям — такое часто добавляют API в духе GitHub или Stripe.

Создать мок

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 422,
  "content_type": "application/problem+json",
  "response_body": "{\"type\":\"https://quickmock.dev/problems/validation-error\",\"title\":\"Your request parameters didn't validate\",\"status\":422,\"detail\":\"The 'email' field must be a valid email address.\",\"instance\":\"{{mock.url}}/requests/38f0\",\"errors\":[{\"field\":\"email\",\"message\":\"must be a valid email address\"}]}"
}'

Вызвать

curl https://quickmock.dev/m/<slug>

Что вы получите

GET /m/<slug> -> 422 application/problem+json
an RFC 9457 problem document with a custom errors[] extension

Чем это отличается от настоящего

Это одна фиксированная ошибка валидации — status, detail и расширение errors[] захардкожены; поправьте тело ответа, чтобы воспроизвести именно тот сбой, который должен обработать ваш клиент, а не общий 422.

Источники

Частые вопросы

Что такое problem+json и зачем он нужен?: Это формат ошибок, стандартизованный в RFC 9457: небольшой согласованный набор полей, чтобы клиенты и логи читали ошибки любого API одинаково, вместо того чтобы каждый сервис выдумывал собственную обёртку.
Почему status есть и в теле, и в ответе?: Поле status в теле дублирует HTTP-статус, чтобы залогированный или переданный дальше документ оставался осмысленным в отрыве от ответа. RFC 9457 требует, чтобы они совпадали, и расхождение — это баг, на который стоит завести проверку.
Массив errors — часть стандарта?: Нет. RFC 9457 разрешает поля-расширения, и errors — одно из них: детализация по полям, которую обычно добавляют API в стиле GitHub или Stripe. Клиенту стоит считать стандартные поля гарантированными, а расширения — необязательными.

Готовы попробовать?

Открыть в конструкторе моков и сначала поправить

Хорошо сочетается с гайдом: Замокать конкретную ошибку