intermediate

REST error response shape

Возвращайте consistent machine-readable errors с codes, messages, field details, correlation IDs и safe diagnostics.

Единообразные error bodies ускоряют обработку на клиенте, поддержку инструментов и корреляцию инцидентов. [RFC 9457 Problem Details](https://www.rfc-editor.org/rfc/rfc9457) — хорошая база.

					{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation failed",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/orders/req-abc123",
  "errors": [
    { "field": "email", "code": "invalid_format", "message": "Must be a valid email" }
  ],
  "correlationId": "7c9e6679-7425-40de-944b-e07fc1f90ae7"
}

Правила проектирования:

Стабильный `type` или `code` для программной ветвления (не английский prose).
Человекочитаемые `title`/`detail` для логов и UI; локализация на клиенте где возможно.
Field-level `errors[]` для форм; никаких stack traces или SQL.
`correlationId` совпадает с логами и tracing (также `X-Request-Id`).

На интервью: problem+json против ad-hoc `{ error: string }`, маппинг domain errors на HTTP status, что безопасно в public APIs.

Типовые ошибки: новый JSON ошибок на каждый релиз, смешение validation и auth errors, внутренние имена исключений, 200 с флагом ошибки в теле.

Компромисс: богатые детали ошибок против information disclosure — настройка под аудиторию (public vs internal).

Чеклист:

Стабильные machine codes; human messages отдельно.
correlationId в каждом error response.
Field errors для validation; generic message для 500.
Каталог ошибок в OpenAPI.