kakaoChannel: false
<body>
<div class="notion-page-content padding">
<div id="darass"
data-project-key="MGxNT547E7u0i1i466"
data-dark-mode="false"
data-primary-color="#10DF99"
data-show-sort-option="true"
data-allow-social-login="true"
data-show-logo="true"
style="flex-shrink:0;flex-grow:1;display:flex;align-items:center;flex-direction:column;color:rgb(55, 53, 47);padding-top:5px;padding-bottom:var(--page-content-padding-bottom);margin:0 auto;"
>
<script type="text/javascript" defer>
(function () {
var $document = document;
var $script = $document.createElement("script");
$script.src = "<https://reply-module.darass.co.kr/embed.js>";
$script.defer = true;
$document.head.appendChild($script);
})();
if (window.matchMedia("(min-width: 400px)").matches) {
document.getElementById("darass").style.maxWidth = "730px";
} else {
document.getElementById("darass").style.maxWidth = "400px";
}
</script>
</div>
</div>
</body>
⬅️ 이전 글 : 없음
‣
➡️ 다음 글 : 없음
**ATDD 강의** 코드리뷰 중 이런 질문을 받았다. 질문의 요지는, /stations/{id} 혹은 /stations?name={name} 등과 같은 요청에 해당하는 데이터가 없을 경우, 어떤 응답코드가 적절한가이다.
HTTP Status Code에 대해서는 나름대로 기준을 세웠던지라 별다른 고민은 없었는데, 팀원과 이야기 중에 생각이 다른 부분이 있어 다른 리뷰어들과도 이야기를 나누어보았다. 이 내용을 정리하고 공유하고 또 다른 의견들을 듣는 것도 좋을 거 같아 포스팅해본다.
우선, 200이 적절하다는 주장을 살펴보자.
HTTP에서 이야기하는 resource 라는 개념을 서버 데이터와 엮지 않고 온전히 URI 라고 보아야 한다. 즉, 서버의 데이터 없음을 HTTP resource와 엮지 않아야 한다는 것으로, 위의 경우에는 빈값의 200 응답을 해야 한다는 것이다.
다만, DELETE 메서드에서 없는 데이터를 삭제하려고 했을 때 이 요청은 400 에러로 처리하여야 하는데, 이는 서버에서 요청이 수용되었으나 클라이언트의 요청이 잘못되었음을 의미하기 때문이다. 이렇게 리소스와 데이터 자원을 분리하는 이유는 명확함을 강조하기 위함이다.
그리고 REST를 지향하는 API에서도, 삭제를 실행 했을 때 그 데이터가 삭제 가능한 상황을 단순하게 데이터가 존재한다고 판단하지 않는다. 그 데이터에 얽혀있는 비지니스적인 요소에 따라 요청 클라이언트에게 데이터가 없다고 밝혀야 할 수도 있고, 삭제가 불가능하다고 밝혀야 할 때도 있다.
가령, 주문을 실행한다고 했을 때 주문이 실행 불가능한 여러가지 경우가 있다. 재고가 떨어져서, 혹은 판매자가 폐업한 경우 등의 상황에서 404, 400, 500 에러는 적절치 않다. 리소스 수용이 정상적으로 이루어졌고, 요청한 데이터에도 이상이 없고(클라이언트에게 책임이 없고), 서버에서 비정상적이고 식별 불가한 에러를 발생한 것도 아니므로 200 응답을 주는 것이 적절해 보인다. 다만 클라이언트에서 식별에 대한 응답을 하기 위해 요청은 성공했지만 주문에는 실패했다는 의미로 내부적으로 관리되는 상태 코드를 응답 body 에 명시하도록 한다. 이러한 사용은 실제 서버에 이상이 있는지, 클라이언트가 잘못된 요청을 하는지에 대한 구분을 명확히 함으로써 장애시 트래킹 포인트를 좁히는데에도 큰 역할을 한다.
즉, 조회시 없을 때는 200, PUT/DELETE의 경우 상황에 따라 (데이터가 있어야하는데 없는 경우) 4xx, 아니면 200에 응답 body에 별도로 메시지나 정책적으로 만든 상태코드를 담아서 보내는 것이 적절하다는 주장이다.
위의 주장은 현재 국내 몇 군데 규모있는 회사 개발자들의 의견이었고, 나 역시 그렇게 생각하고 있었다. 그래서 확인차 몇군데 둘러보니 실제로 그렇게 운영되고 있다.