Почему для эндпоинта авторизации не следует использовать HTTP метод PUT?

Использование PUT для авторизации нарушает семантику HTTP и принципы REST, создавая проблемы с безопасностью и кэшированием.

Семантическое несоответствие:

• PUT — идемпотентный метод для создания/замены ресурса по известному URI. Он предполагает работу с конкретным ресурсом (PUT /users/123).
• Авторизация — это действие (action), которое не создает напрямую ресурс, а инициирует сессию или выдает токен. Оно не является идемпотентным (повторный запрос с теми же данными может выдать новый токен).

Практические проблемы:

1. Кэширование: Прокси и кэши могут кэшировать PUT-запросы, что недопустимо для данных аутентификации.
2. Логирование: Тела PUT-запросов могут логироваться, подвергая риску учетные данные.
3. Неясность API: PUT /auth — что это заменяет? Это противоречит ожиданиям клиента.

Правильный подход — использовать POST:

POST /api/auth/login HTTP/1.1
Content-Type: application/json

{
  "username": "user",
  "password": "pass"
}

@RestController
public class AuthController {
    @PostMapping("/auth/login") // POST для неидемпотентного действия
    public ResponseEntity<AuthResponse> login(@RequestBody LoginRequest request) {
        // ... аутентификация ...
        return ResponseEntity.ok(new AuthResponse("jwt-token-here"));
    }
}

Вывод: Для операций, не соответствующих CRUD над ресурсом (логин, логаут, расчет), всегда используйте POST.