- Пользователь может добавлять, удалять, закрывать и заново открывать задачи
- Названия задач должны быть уникальными для всех пользователей (удаленные не учитываются).
- Пользователь может получить список всех задач любого другого пользователя, кроме удаленных.
- Пользователь может закрывать, удалять и заново открывать только свои задачи
- Задача проходит следующие состояния:
CREATED <--> CLOSED -> DELETED
. При этом задача в статусеCREATED
не может сразу перейти вDELETED
. Задача же вDELETED
больше не может переходить ни в какое состояние.
Веб-сервер принимает сообщения по придуманному нами протоколу - Simple Web Protocol.
Запросы и ответы состоят из одной строки.
Формат запроса: “USER COMMAND ARG”
Формат ответа: “RESULT ARG”
USER
- имя пользователя, который осуществляет действияCOMMAND
- команда. Варианты команд:CREATE_TASK MyTask
- создать задачу с названием MyTaskDELETE_TASK MyTask
- удалить задачу MyTaskCLOSE_TASK MyTask
- закрыть задачу MyTaskREOPEN_TASK MyTask
- заново открыть задачу MyTaskLIST_TASK USER
- Получить список задач пользователя
ARG
- аргумент запроса или ответа. Может отсутствовать.RESULT
- ответ сервера о совершении действия. Варианты ответов.CREATED
- задача успешно созданаDELETED
- задача успешно удаленаCLOSED
- задача успешно закрытаREOPENED
- задача успешно открыта зановоTASKS [MyTask1, MyTask2]
- список задач пользователя. Если задач нет, список пустой ([]
)WRONG_FORMAT
- Неверный формат запросаACCESS_DENIED
- Нет прав на совершение операцииERROR
- Любая другая ошибка
- Все команды, а также имена пользователей регистрозависимые
- Запросы валидируются в следующем порядке: формат запроса, право на совершение операции, все остальные проверки. Если первая проверка не прошла, остальные не выполняются.
VASYA CREATE_TASK CleanRoom
CREATED
PETYA DELETE_TASK CleanRoom
ACCESS_DENIED
PETYA CREATE_TASK Task1
CREATED
PETYA CREATE_TASK Task2
CREATED
VASYA LIST_TASK PETYA
TASKS [Task1, Task2]
VASYA CREATE_TASK CleanRoom
ERROR
В ServerTest
необходимо добавить тест-кейсы, которые проверят корректность вышеописанных фич.
Все данные храним в оперативной памяти. Concurrency-эффекты не учитываем, так как сервер обрабатывает запросы последовательно.
Spring, прочие фреймворки и вспомогательные библиотеки использовать нельзя. Применяем только то, что уже есть в проекте.
Учитывается общее оформление кода, архитектурное разделение компонентов, а также наличие Unit-тестов на отдельные части проекта.
- Форкаем репозиторий.
- Создаем новую ветку от
master
. - Выполняем задание и пушим изменения.
- Создаем Pull Request из своей feature-ветки в
master
исходного репозитория. - В комментарии оставляем ФИО и почту (тегаем @SimonHarmonicMinor)
- Ждем результатов :)
Для приема задания необходимо, чтобы билд проходил успешно (команда ./mvn package
). Перед
отправкой изменений, пожалуйста, проверьте, что команда отрабатывает локально.