[HTTP] HTTP 메서드 멱등성

DELETE 메서드는 멱등해야한다.

HTTP DELETE 메서드는 원칙적으로 멱등(Idempotent) 해야 한다. 즉,

“같은 DELETE 요청을 여러 번 보내도 서버의 최종 상태는 동일해야 한다.”

예를 들어 /todos/1/managers/10 을 삭제할 때:

• 첫 번째 요청 → manager 정상 삭제
• 두 번째 요청 → 이미 삭제된 상태지만
  • 서버의 최종 상태는 동일(삭제됨)
  • 실패가 아니라 성공처럼 처리

---

내가 받은 피드백의 핵심 - 두 번째 DELETE 요청이 실패하면 UX가 깨진다

다음과 같은 피드백을 받았다.

ManagerController delete 메소드의 인증된유저 처리 문제 에서 HTTP Method중 DELETE는 멱등성을 준수합니다. 제공하는 기능에 따라 멱등성을 준수하지 않도록 만들어야 할 수 도 있지만 기본적으로는 같은 값으로 요청을 보내도 동일한 결과를 주어야합니다. 모종의 이유로 인해 사용자가 보낸 요청이 빠르게 두번 연속으로 서버로 보내질 경우 두번째 요청으로 인해 유저가 보는 화면에서는 결국 오류가 발생했다고 느낄 수 있기 때문이죠. API 기능 설계 UX도 고려가 되면 좋겠습니다

문제가 발생할 수 있는 내코드는

Todo todo = todoRepository.findById(todoId)
        .orElseThrow(() -> new InvalidRequestException("Todo not found"));

문제

• 첫 번째 요청 → Todo와 Manager 모두 존재 → 정상 삭제
• 두 번째 요청 → Manager는 이미 삭제됨, 심지어 Todo도 존재하지 않을 수 있음

→ 결과적으로 예외 터짐
→ 사실은 이미 삭제된 것이므로 정상 상태인데도 사용자는 삭제가 실패한 것처럼 느낌 (UX가 깨짐)

DELETE 멱등성을 지키기 위해서는
두 번째 요청에서도 예외가 나지 않게 설계해야 한다.

---

개선 방향

1. Todo 조회가 중요할까?

• DELETE의 목적은 Manager 삭제
• Todo가 존재하는지는 두 번째 요청 이후에는 중요하지 않다.

Manager manager = managerRepository.findById(managerId)
        .orElse(null);

if (manager == null) {
    return; // 이미 삭제됨 → 멱등성 충족
}

• manager만 먼저 조회해 이미 삭제되었을시 바로 리턴
• delete 호출은 1번만 일어남

2. 조회 실패는 조용히 넘어감

• DELETE는 같은 요청을 여러 번 보내도 정상처럼 보이는 게 규약
• 권한이 잘못되면 Forbidden이 맞지만 이미 삭제된 리소스(NotFound)는 멱등성이 보장된 정상 종료여야 함

---

배운점

서비스 로직을 만들때 이 코드가 UX에 어떤 영향을 미치는가도 함께 고민해야 한다는 사실을 리마인드 하게되었다.