Files
docs/architecture/http-api.md
T

85 lines
6.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# HTTP API и ошибки
## Источник контракта
Backend генерирует OpenAPI из собственного публичного API. Frontend использует
производное описание контракта и типизированный клиент. Изменения проходят
[contract workflow](../development/runtime-openapi-verification.md).
API имеет prefix `/api/v1`; Swagger публикуется для локальной разработки по
environment policy, а не используется frontend в runtime.
## Validation и identity
Backend преобразует и проверяет входные данные на общей HTTP-границе.
Неизвестные свойства запроса удаляются; сам факт их передачи не обещает отказа.
Проверка формата не заменяет бизнес-ограничения и проверку доступа к счёту.
Аутентификация подтверждает личность пользователя; accountId из URL сам по себе
не доказывает доступ к брокерским данным.
## Error contract
Общая граница обработки HTTP-ошибок возвращает `application/problem+json`
со `status` и публичным `code`.
Неожиданный exception возвращает `500` / `INTERNAL_SERVER_ERROR`, без исходного
message/stack. Типичный ответ:
```json
{ "status": 401, "code": "UNAUTHORIZED" }
```
Для input validation контракт требует `400`, `VALIDATION_ERROR` и `errors` как
массив `{ pointer, detail }`, где pointer адресует поле запроса. Это требование
не считается проверенным одним описанием OpenAPI: нужна проверка реального
HTTP-ответа после всех стадий обработки запроса.
**Известное расхождение:** согласованная
[спецификация аутентификации](../../specs/openspec/specs/user-authentication/spec.md#requirement-стандартные-ответы-об-ошибках)
требует `pointer` и `detail` для невалидных полей. В текущей конфигурации
валидация формирует строковые сообщения, а фильтр ожидает структурированные
ошибки полей; поэтому корректность деталей `errors` не подтверждена.
Исправление требует отдельного изменения реализации и проверки полного
HTTP-потока. OpenAPI сам по себе этого расхождения не устраняет.
Ответ не включает автоматически все поля RFC (`type`, `title`, `instance`).
Добавление обязательного поля является изменением публичного контракта.
Клиент выбирает поведение по публичному коду, а не по внутреннему тексту ошибки.
## Domain errors и auth
Специальный code определяется сценарием; общее преобразование ошибок и безопасная
форма ответа принадлежат HTTP-границе. Auth endpoints используют свои status и cookie
operations: [Authentication](../domains/authentication/overview.md).
T-Bank token failure и временная недоступность имеют разные значения:
[Connection API](../integrations/tbank.md#состояние-и-ошибки). Raw upstream/Prisma errors
и secrets не передаются frontend.
## Граница доказательства
Сравнение OpenAPI подтверждает согласованность схем, а не результат каждого
запроса. Безопасная обработка неожиданной ошибки проверяется отдельно.
Валидация, доступ, статусы и cookie требуют проверки полного HTTP-потока;
атомарность хранения — проверки с изолированной реальной базой.
Известное ограничение сквозных проверок описано в
[проверке backend](../development/verification.md).
## Наблюдаемость
Backend пишет структурированные JSON-события в stdout через Pino. Обработка
HTTP-запроса получает серверный request ID, который возвращается заголовком
`X-Request-ID`; допустимый входящий идентификатор сохраняется отдельно как
client request ID. Это позволяет сопоставить публичную ошибку с обработкой
запроса без передачи внутреннего exception в ответ API.
Журнал завершения запроса содержит шаблон маршрута, метод, статус,
длительность и при наличии публичный error code. События внешней границы
добавляют операцию, результат и число попыток. Разрешённые поля ограничены;
полные запросы и ответы, token, cookie и Authorization не являются данными
журнала. Фильтрация полей и redaction не защищают секрет, вручную включённый
в свободный текст сообщения или stack.
Выбор logger и граница ответственности описаны в
[ADR 008](../adr/008-pino-backend-logging.md); согласованное поведение — в
workspace-спецификации
[Structured logging](../../specs/openspec/specs/backend-structured-logging/spec.md).
Сборщик, срок хранения журналов и alerting не определяются приложением.