Какие HTTP методы и пути использовать для создания и получения аккаунтов

Что проверяют

Знаете ли вы базовые соглашения REST и можете ли довести их до рабочего контроллера. Следом обычно спрашивают, какие коды возвращать и как не отдать лишнее, например хэш пароля или чужой аккаунт.

Как отвечать

Ресурс называется существительным во множественном числе, глагол живёт в HTTP-методе:

• POST /api/v1/accounts: создание. Ответ 201 Created, заголовок Location: /api/v1/accounts/{id} и тело с созданным аккаунтом;
• GET /api/v1/accounts/{id}: один аккаунт, 200 или 404;
• GET /api/v1/accounts?email=...&page=0&size=20: список с фильтрами и пагинацией;
• GET /api/v1/accounts/me: текущий пользователь без передачи id в пути.

Ошибки тоже часть контракта: 400 на невалидное тело, 409 на уже занятый email, 401 без аутентификации, 403 без прав. Тело ошибки удобно отдавать в формате Problem Details (RFC 9457), в Spring для этого есть ProblemDetail.

В Spring это @RestController с @RequestMapping("/api/v1/accounts"), методы с @PostMapping и @GetMapping("/{id}"), тело через @RequestBody @Valid, id через @PathVariable. Ответ на создание: ResponseEntity.created(uri).body(dto), где адрес собирается через ServletUriComponentsBuilder.fromCurrentRequest().path("/{id}"). Наружу уходит отдельный DTO, а не JPA-сущность: так в ответ не попадёт пароль и не сработает ленивая загрузка при сериализации.

Про повторную отправку: POST не идемпотентен, поэтому для клиентских ретраев нужен ключ идемпотентности или PUT /accounts/{id} с идентификатором, который генерирует клиент.

Где спотыкаются

Пишут глаголы в путях: /createAccount, /getAccountById. Это RPC поверх HTTP, а не REST.

Отвечают 200 на создание и не возвращают Location. Клиенту приходится угадывать, где искать новый ресурс.

Проверяют только аутентификацию. Без проверки владельца GET /accounts/{id} отдаст любой аккаунт по перебору id: это классическая IDOR-уязвимость, и последовательные числовые id её только облегчают.