Status: Accepted
Date: 2026-04-18
Референсный сервис и первая версия GlobalExceptionHandler использовали самописный JSON:
{"error": "INTEGRATION_ERROR", "message": "Сервис недоступен", "detail": "...", "timestamp": "..."}
Это работает, но не стандарт. Клиентам (фронту, SDK, Postman) нужна документация именно нашего формата ошибок вместо общепринятого. Сборщики ошибок (Sentry, Datadog) не умеют парсить кастомный формат "из коробки".
Переходим на RFC 9457 Problem Details for HTTP APIs (обновлённая версия RFC 7807):
ProblemDetail из @ExceptionHandler. Spring 7 сам пишет Content-Type: application/problem+json.type: относительный URI /problems/{slug}, вложенные через / (integration/unreachable).instance проставляется Spring автоматически из URL запроса.ProblemDetail.setProperty(...).GlobalExceptionHandler extends ResponseEntityExceptionHandler — даёт бесплатно обработку встроенных Spring MVC exceptions (валидация @Valid, parse ошибки тела) в том же формате.Самописный ErrorResponse record удалён (его никто не использовал напрямую кроме handler'а).
Positive:
type на абсолютный URL (один константный префикс) когда появится docs-сайт.Negative:
UNPROCESSABLE_ENTITY → UNPROCESSABLE_CONTENT (Spring 7 переименовал под RFC 9110).type: /problems/... сейчас не резолвится — когда клиент попытается кликнуть, 404. Обещание на будущее завести статическую страницу документации.ErrorResponse дальше: теряем стандарт, приходится документировать.urn:crcm:problem:not-found): честнее ("это не URL"), но непривычно, клиентам объяснять.