$ ./gradlew bootRun
-
✅ Можно посмотреть все ручки в swagger'е
-
✅ Использован Spring Security с кастомным
UserDetails, хранящим пользователей в БД -
✅ Увидеть настройки авторизации можно в SecurityConfig
-
✅ Используется Spring Boot Actuator с кастомным
HttpExchangeRepository, сохраняющим базовую информацию о запросе в БД. Endpoint стандартный
✅ Используется Spring Boot Caching с cache provider'ом Caffeine, позволяющим настроить размер кэша и политику устаревания. С текущими настройками кэш устаревает в течение 10 секунд после получения от placeholder из соображений возможности обновления данных placeholder другими пользователями. Абстракция Spring Boot Caching не позволяет получить id нового объекта, поэтому POST - единственный метод, который не влияет на кэш.
❓ Не понял, что имеется в виду во втором предложении. Возможно имелось ввиду стандартное применение кэша, которое я и реализовал, - сначала данные должны проверяться в кэше, а только потом запрашиваться у placeholder. Либо подразумевается отправление POST, PUT и DELETE запросов к placeholder асинхронно, но тогда не ясно, как сообщать пользователю, если placeholder ответит 5xx.
-
gradle ✅
-
ведение аудита ✅ и хранения пользователей ✅.
-
✅
POST /admin/register -
✅ 11 ролей
-
✅ Тестов немного: бизнес-логики мало, поэтому тестирование оставшихся классов будет копи-пастой либо просто проверкой вызовов классов предыдущего слоя.
✅ Для авторизации и ролевой модели использован тот факт, что для handshake'а в websocket'е используется
http запрос: на нем и установлены настройки авторизации. То есть для подключения по websocket'у нужен
тот же header Authorization, что и для http запроса.
✅ В этот раз аудит осуществляется вручную с сохранением в БД.
Добавлен также кастомный endpoint для Actuator'а - websocketexchanges.
Можно заметить, что на PUT по несуществующему id placeholder отправляет 500. Мне кажется это неправильной обработкой запроса, поэтому мой сервис в данном случае тоже отправляет 5xx код. Было бы неправильным на основании кода возврата 500 делать вывод об отсутствии ресурса (404), так как в какой-то момент placeholder может отправить 500 действительно из-за внутренней ошибки.
При общении с placeholder и при обработке запросов пользователей сервис использует одни и те же DTO. Мне кажется это оправданным в рамках этой задачи, но уточню, что если бы осуществлялась какая-то бизнес-логика, работающая с полученными данными, вероятно DTO следовало бы разделить и производить маппинг на сервисном слое.
Возможно "реализовать кэш" понималось написать его самому. В таком случае, я уже решал аналогичную задачу, где писал кэш на двусвязном списке.