Skip to content

Бэкенд для проверки отчетов (2024) #13

Open
@markpolyak

Description

@markpolyak

Задача

Реализовать серверное приложение (REST API) для проверки отчетов студентов

Описание входных и выходных данных

Входные данные:

  1. POST запрос с телом multipart/form-data из двух частей: JSON-объект с описанием отчета и сам отчет в виде двоичного файла.
  2. POST запрос с телом application/json, в котором содержится JSON-объект с описанием отчета, отличающийся от аналогичного запроса выше наличием поля "report_link". В ходе обработки запроса бэкенд самостоятельно скачивает отчет по приведенной ссылке.
JSON-объект с описанием отчета
{
  "student": {
    "name": "Иван",
    "surname": "Иванов",
    "patronymic": "Иванович",
    "group": "4931"
  },
  "report": {
    "subject_name": "Операционные системы",
    "task_name": "ЛР1. Знакомство с командным интерпретатором bash",
    "task_type": "Лабораторная работа",
    "teacher": {
      "name": "Юлия",
      "surname": "Антохина",
      "patronymic": "Анатольевна",
      "status": "Ректор, д.т.н., проф."
    },
    "report_structure": [
      "Цель", "Задание", "Результат выполнения", "Выводы"
    ],
    "uploaded_at": "2022-06-01T00:00:00Z"
  },
  "report_link": "/get-report-t/d37a5eb4013d68149ce209d4a54d394e"
}

Поле patronymic может быть пустым (None в Python) или ключ может отсутствовать вовсе.
Поле group может содержать буквы, поэтому тип - строка.
Поле uploaded_at содержит дату загрузки студентом отчета в личный кабинет в формате ISO 8601 в часовом поясе UTC.
Поле report_link в первом POST-запросе может отсутствовать, но является обязательным во втором запросе. Если хост не указан, подразумевать https://pro.guap.ru.

Выходные данные:

JSON с информацией о результатах валидации отчета. Код возврата 200, если отчет успешно прошел валидацию, и 422, если отчет не прошел валидацию. Другие коды возврата в случае возникновения ошибок на стороне сервера (5XX) или обнаружения ошибок во входных данных (400 - bad request).
Пример 1:

{
  "status": "Успешно",
  "parser": "docx",
  "results": [] 
}

Пример 2:

{
  "status": "С ошибками",
  "parser": "pdf",
  "results": [
    "Неправильное название предмета",
    "Неверное ФИО студента",
    "Неверная дата"
  ] 
}

Пример 3 (код ответа 400):

{
  "status": "error",
  "message": "описание исключения (ошибки)",
  "parser": null,
  "results": [] 
}

Требования к работе модуля

Реализовать два эндпоинта с помощью Fast API. Автоматическая генерация документации (OpenAPI 3.0, Swagger UI) из кода.

Возможность включить rate limit на запросы, указав специальный ключ при запуске сервера:

  • 1 запрос в минуту к эндпоинту, принимающему бинарный файл с отчетом;
  • 5 запросов в минуту к эндпоинту, принимающему ссылку на файл с отчетом.
    По умолчанию rate limit выключен.

Порядок выполнения работы

  1. Подготовить заглушки для трех модулей, реализующих проверку отчетов студентов в форматах docx, pdf и odt.
  2. Реализовать алгоритм определения формата файла отчета (MS Word, PDF, Open Document Format): расширение, сигнатура (только PDF / не PDF), попытка открыть разными библиотеками.
  3. Реализовать REST API.
  4. Подготовить docker-файл для запуска бэкенда в докере.
  5. Оформить проект в виде питоно-пакета (setup.py, requirements.txt и пр.)
  6. Согласовать список тестов.
  7. Подготовить тестовые данные, реализовать тесты с использованием requests и pytest.
  8. Автоматизировать запуск тестов с помощью GitHub Actions.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions