18 lines
1.6 KiB
Markdown
18 lines
1.6 KiB
Markdown
# Задача 2 — Проверка API-доков по личным данным и сессиям
|
||
|
||
## Что проверяем
|
||
1. В `03_Session_Management_API.md` описан формат `sessionId` и правило «передавать как есть».
|
||
2. В `04_Add_Block_to_Blockchain_API.md` описан набор ключей USER_PARAM для личных данных.
|
||
3. В `05_Technical_Requests_API.md` зафиксировано, что отдельного RPC для direct tech message в конкретную сессию пока нет.
|
||
|
||
## Как должна выглядеть рабочая логика
|
||
- Клиент сохраняет личные данные через `UpsertUserParam` по стандартным ключам.
|
||
- При повторном изменении поля клиент пишет новую запись с более поздним временем.
|
||
- Актуальное значение получается через `ListUserParams` (берётся самая новая запись по ключу).
|
||
- Для отправки техсообщений в конкретную сессию нужен отдельный RPC, которого пока нет.
|
||
|
||
## Критерии приёмки
|
||
- Термины и пояснения в документации понятны без чтения кода.
|
||
- Примеры ключей единообразны (`name`, `last_name`, `address_physical`, `address_web`, `phone`).
|
||
- Ограничения MVP явно указаны (ACL/валидация/отдельный direct-session RPC).
|