5.5 KiB
5.5 KiB
Frontend Integration Guide
Этот документ нужен фронтенду как краткая рабочая инструкция по интеграции с SparkGuardBackend.
Что использовать как основной контракт
Frontend-команде нужно отдать три файла:
cmd/rest/controllers/docs/swagger.json— машинно-читаемый OpenAPI/Swagger контракт.docs/api/README.md— краткий REST-обзор по сценариям и смыслу ручек.docs/frontend/README.md— этот документ с прикладными рекомендациями для экранов и polling flow.
Базовые принципы
- frontend общается только с backend;
- frontend не ходит в
SparkGuardAntiplagiarism, Kafka или MinIO; - upload и check — это два разных шага;
- dashboards должны использовать
summary/statsendpoints, а неchunks; chunksиreport.raw.json— только debug/admin слой.
Авторизация
Вход
POST /auth/login
Ответ:
{
"user": {
"id": 1,
"name": "Admin",
"email": "admin@example.com",
"access_level": "Admin"
},
"token": "jwt"
}
Текущий пользователь
GET /auth/me
Передавать:
Authorization: Bearer <jwt>
Справочники и CRUD
Основные сущности:
usersstudentsgroupseventsworksreference-sets
Для большинства таблиц frontend может опираться на стандартный CRUD:
- list:
GET - create:
POST - get one:
GET /:id - update:
PATCHилиPUT - delete:
DELETE
Основной flow проверки работы
1. Создать work
POST /works
2. Загрузить архив
PUT /works/:id/archive
Поддерживаются:
- raw
application/octet-stream multipart/form-data
Ответ:
{
"message": "archive uploaded",
"status": "Stored",
"archive_object_key": "submissions/12/101.zip",
"archive_checksum": "sha256...",
"archive_size": 20480
}
3. Запустить проверку
POST /works/:id/check
Ответ:
{
"message": "analysis queued for current archive",
"analysis_run_id": "uuid",
"status": "Queued"
}
4. Poll статуса
GET /analysis-runs/:id
Frontend должен ждать состояния:
QueuedProcessingCompletedFailed
Рекомендуемый polling:
- каждые
2-3секунды первые30секунд; - затем каждые
5секунд; - останавливать polling на
CompletedилиFailed.
5. После завершения читать результат
GET /analysis-runs/:id/adoptionsGET /analysis-runs/:id/report.jsonGET /analysis-runs/:id/report.htmlGET /analysis-runs/:id/report.pdfGET /works/:id/summary
Какие endpoints использовать для экранов
Экран списка/карточки работы
GET /worksGET /works/:idGET /works/:id/analysis-runsGET /works/:id/summary
GET /works/:id/summary — основной endpoint для детального экрана работы.
Он уже отдаёт:
presentation_summarytrust_scoreplagiarism_rate- strongest counterpart
counterpartsgraph- latest run metadata
Экран события
GET /eventsGET /events/:idGET /events/:id/worksGET /events/:id/summary
Экран группы
GET /groupsGET /groups/:idGET /groups/:id/stats
Экран студента
GET /studentsGET /students/:idGET /students/:id/stats
Экран отчёта преподавателя
- основа:
GET /analysis-runs/:id/report.json - экспорт:
GET /analysis-runs/:id/report.htmlGET /analysis-runs/:id/report.pdf
Экран аудита
GET /audit-logs
Фильтры:
actor_user_idactionresource_typeresource_idsourcelimit
Этот endpoint нужен только для admin UI.
Что означает summary/statistics payload
Во всех summary/stats ручках frontend получает одинаковые строительные блоки:
presentation_summaryworksgraph
presentation_summary
Основные поля:
works_totalworks_checkedworks_completedworks_failedworks_flaggedcounterparts_countconnections_countplagiarism_ratetrust_scorerisk_levelheadline
graph
nodes— вершины графа работ;edges— связи между работами;- использовать для экрана "
кто с кем совпадает".
Что не нужно использовать для продуктового UI
GET /analysis-runs/:id/chunksGET /analysis-runs/:id/report.raw.json
Они нужны для:
- отладки пайплайна;
- технической диагностики;
- проверки Kafka/analyzer boundary.
Ошибки
Формат ошибок стабилен:
{
"message": "Краткое описание",
"error": "Технические детали"
}
Для UI обычно показывать:
messageпользователю;error— только в debug/admin mode.