$ ./gradlew bootRun

1. ✅ Можно посмотреть все ручки в swagger'е

2. ✅ Использован Spring Security с кастомным UserDetails, хранящим пользователей в БД

3. ✅ Увидеть настройки авторизации можно в SecurityConfig

4. ✅ Используется 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.

0. gradle ✅

1. ведение аудита ✅ и хранения пользователей ✅.

2. ✅ POST /admin/register

3. ✅ 11 ролей

4. ✅ Тестов немного: бизнес-логики мало, поэтому тестирование оставшихся классов будет копи-пастой либо просто проверкой вызовов классов предыдущего слоя.

✅ Для авторизации и ролевой модели использован тот факт, что для handshake'а в websocket'е используется http запрос: на нем и установлены настройки авторизации. То есть для подключения по websocket'у нужен тот же header Authorization, что и для http запроса.

✅ В этот раз аудит осуществляется вручную с сохранением в БД. Добавлен также кастомный endpoint для Actuator'а - websocketexchanges.

Можно заметить, что на PUT по несуществующему id placeholder отправляет 500. Мне кажется это неправильной обработкой запроса, поэтому мой сервис в данном случае тоже отправляет 5xx код. Было бы неправильным на основании кода возврата 500 делать вывод об отсутствии ресурса (404), так как в какой-то момент placeholder может отправить 500 действительно из-за внутренней ошибки.

При общении с placeholder и при обработке запросов пользователей сервис использует одни и те же DTO. Мне кажется это оправданным в рамках этой задачи, но уточню, что если бы осуществлялась какая-то бизнес-логика, работающая с полученными данными, вероятно DTO следовало бы разделить и производить маппинг на сервисном слое.

Возможно "реализовать кэш" понималось написать его самому. В таком случае, я уже решал аналогичную задачу, где писал кэш на двусвязном списке.