HTTP: Delete method에 대한 두 가지 생각

프로젝트를 진행하다 보니까 시간이 정말 없다. 시간이 없는데 코딩도 해야 하다보니깐, 코딩하면서 드는 생각들을 정리할 시간이 없어 아쉬웠다. 오늘도 저녁 즈음 코딩을 하다가 '아.. 이런걸 정리할 시간이 있어야 나의 작고 소중한 블로그에도 새 글이 꾸준히 올라올텐데...'라는 생각이 들었던 점이 있어서, 요거 한번 짤막하게 포스팅해보자! 싶어서 가져와보았다.

생각 1: Delete를 위한 payload, 괜찮을까?

---

딜리트(물론 소프트 딜리트)를 실행하려는 로직이 있었다. 해당 엔드포인트를 위한 핸들러를 만드는데, 단순히 삭제할 데이터의 식별자 외에 받아야 할 데이터가 조금 있었다.

(당연히)보안에 치명적이지는 않지만, 그래도 사용자에게 보여주는 것보단 가려주는게 더 좋은 필드였다. 다른 말로 해서, query string이나 path variable로 나타내지 않는 편이 좋은 값이었다.
나는 단순하게 생각했다. 그럼 request body에 실어보내면 되겠네, payload로.

그렇게 생각하고, 그렇게 코딩하기 전에, 다행히도 확인을 해보기로 했다. 결론적으로 그렇게 하는 것은 적절치 않았다.
HTTP DELETE는 payload가 있어서는 안된다!...라고 말하는 블로그도 많았지만 사실 그렇지는 않고, 스펙을 보면 HTTP DELETE는 payload에 대한 어떠한 기본 동작이 정의되어있지 않다. 그러니까 넘어온 바디를 처리해주는 경우도 있을 수 있고, 값을 무시해버리거나 에러를 반환해도 무방하다.
이렇게도 될 수 있고 저렇게도 될 수 있는 처리 방식이라면, 그렇게 처리해서는 안된다(적어도 내 생각에는).

그럼... 일반 사용자에게 가려진 채로 데이터를 보내고 싶으면 뭐떻게 보내야 할까?
결론. 헤더에 실어 보내자.

물론 이것도 하나의 방법이 될 수 있을 뿐이지 정확한 정답은 아니다.
하지만 헤더에 '값'을 실어보낼 생각은 애초에 해 본 적이 없어서, 신선한 생각이었다.

생각 2: Delete하려고 했는데 지울 수가 없는 데이터래요... 이 상황에 응답으로 적절한 HTTP Status는?!

---

어찌저찌 실어보내서 서비스를 구현하다 문득 생각이 들었다.
어떤 로직이었냐면, 이미 삭제한 데이터를 다시 삭제하려고 요청한 경우였던 것 같다(솔직히 말하면 다른 로직이었던 것 같은데 기억이 안난다).

하여튼 어떤 이유에서인지 데이터를 지울 수 없는 경우였다.

DELETE의 멱등성을 고려하면 그냥 몇번이고 delete를 시켜줘야겠지만 사실 실제 서비스에서는 한 번도 지우지 않는 것이다(소프트 딜리트).
그러면 적절한 Response를 돌려줘야 할 것 같은데... 습관적으로 400번을 내려주려던 순간 의문이 든 것이다.
과연 400번이 적절한 status일까? 이럴 때 사용하는 더 적절한 코드는 없을까?

이것도 결론만 말하면 409 Conflict라는 코드가 있었다. 400번은 비즈니스 로직에서 거절되었다기 보다는 요청 데이터 자체에 결함이 있어서 응답을 거절한다는 느낌이다. 나의 상황에서는 409가 적당했기에, 409번을 태어나서 처음으로 내려보게 되었다 히히.
앞으로는 상황에 따라서 400번과 409번을 적절히 사용할 수 있을 것 같다.
물론 프론트엔드 개발자님께서 "됐고 400번으로 내려주세요"라고 하면 나는 말을 잘 들을 것이다......