204 vs 404

Marsboy·2022년 11월 11일

네트워크

목록 보기

1/2

서론

없는 리소스에 대한 조회?

백엔드 개발을 하는 도중 Swagger를 통해서 API를 문서화하고 있었는데, 없는 리소스에 대한 조회의 반환 상태코드를 204로 할지, 404로 할 지에 대해서 고민하고 있었다. 200번대 상태코드와 400번대 상태코드는 그 의미가 확연히 다르기 때문에 어떻게 전해주냐에 따라서 프론트엔드가 어떻게 작업할 지가 갈리기 때문이다.
내가 고민한 이유에 대해서는 다음과 같다.

404 not found :

없는 리소스에 대한 조회? -> not found 반환
일반적으로 의도되지 않은 비즈니스 로직일 것 -> 400번대 에러

하지만 생각해보니 200번대 상태 코드를 반환하는 게 맞지 않나? 라는 생각도 들었다.

204 no content :

400번대 에러는 클라이언트 개발자의 잘못된 요청을 명시해주는 것 같은 기분이다. 없는 리소스에 대한 조회는 클라이언트 개발자의 잘못된 요청 방식이 아닌, 없는 리소스에 대한 요청일 뿐이므로 204 no content를 반환해야 한다.

그렇게 상태코드를 어떻게 내려주는지 고민하며 구글링을 해본 결과 비슷한 주제로 200번대 vs 400번대로 박터지게 싸우고 있었다. 다양한 국내 블로그부터 스택 오버플로우까지 없는 리소스에 대한 조회에 대해서 끝도 없이 많은 이야기들이 나오고 있었다.

중론

상태 코드(status code)?

우리가 HTTP 통신을 함에 있어서 백엔드와 프론트가 소통할 때 상태 코드는 굉장히 중요하다. 프론트에서 분기를 나누어 로직을 짤 때, 상태 코드를 활용하여 다양한 페이지로 라우팅 시킬 수 있게 된다. 뿐만 아니라 프론트엔드와 백엔드가 소통할 때 HTTP 통신을 기반으로 이루어지는 것을 생각하면, 정확한 상태 코드의 반환은 좋은 아키텍처를 위한 필수 조건이다.

백엔드에서 다양한 프로그램을 짤 때, 프론트엔드에서 작업을 처리할 수 있게 상태 코드를 다채롭게 활용해서 백엔드에서 어떤 상황이 일어나고 있는 지를 전할 수 있어야 한다.

해당 페이지에서 다양한 HTTP의 상태코드를 살펴볼 수 있다.

200번대가 맞다는 의견

statusCode = 204 (NO CONTENT)

나는 상태코드의 204번 no content가 말 그대로 없는 리소스에 대한 조회인 줄 알았으나, no content는 '성공적인 부재'를 알리는데 사용하지 않고, 리소스가 존재하는데 서버가 어떤 이유로 응답 body에 리소스를 포함하지 않기로 선택했음을 나타낸다고 한다.
즉 없는 리소스에 대한 조회로 어떤 상태코드가 적당하냐는 것으로 이야기를 한다면 200 vs 404가 되는 셈이다.
또한 201과 비슷하게 204는 서버가 리소스를 생성하지 않고도 일부 작업을 수행했거나 리소스를 반환하는 것이 관련이 없는 다른 이유로 인해 POST 요청에 대한 응답으로 사용될 수도 있다.
즉, 204 no content는 없는 리소스에 대한 조회에 주로 사용하지 않는다는 것이 일반적인 의견이다.
( 출처 : stackoverflow )

200 (OK)

위에서 없는 리소스에 대한 조회의 반환을

GET /user/xxx/albums
HTTP/1.1 200 OK
[]

위와 같은 식으로 해야한다고 명시했다, 물론 밑에 다양한 반대 의견도 있었지만,

400번대가 맞다는 의견

404 (NOT FOUND)

일반적으로 생각할 수 있는 에러, 없는 리소스에 대한 조회이므로 Not Found가 아닌가?

https://www.rfc-editor.org/rfc/rfc7231

해당 페이지에 쓰인 내용에 따르면 서버가 정상적으로 동작하느냐에 관련 없이, 요청한 리소스가 정상적으로 돌아오는 지에 따라서 판단해야 한다고 한다.

HTTP의 요청 대상이 resource임을 고려하면, 요청한 리소스가 정상적으로 돌아오지 않는다면 404 NOT FOUND가 적절하다는 주장이다.

결론

팀원들과 백엔드 작업을 하는 도중 팀원이 만든 소스 코드를 읽어보면서 맨 처음에는 없는 리소스에 대한 조회로 200 Ok에 빈 페이로드를 담아서 넘겼다. '어? 왜 404가 아닌거지?' 라는 의문이 들어서 혼자서 이것저것 찾아 보다가 해당 논쟁에 휩싸여 끝도 없이 빠지게 됐다.

그래서 협업을 할 때, 나는 해당 규칙에 따라서 HTTP 상태 코드를 만들어야겠다고 판단하게 됐다.

없을 수 있는, 없는 리소스에 대한 조회 -> 200 OK, Empty Payload
없으면 안 되는, 없는 리소스에 대한 조회 -> 404 NOT FOUND

여기서 없을 수 있는이라는 키워드는 GET 메서드를 보내는 경우 없는 리소스에 대해 파라미터로 요청하는 경우를 뜻한다.
해당 요청이 정상적으로 수행됐지만, 서버에는 해당 파라미터와 일치하는 데이터가 없어 빈 페이로드를 200과 함께 반환한다.

없으면 안 되는 키워드는 PUT이나 PATCH, DELETE에 해당한다. GET과는 다르게 리소스에 대해 상식적으로 PATCH나 DELETE를 하는 목적이 어떠한 리소스를 다루기 위함인데
위의 메서드를 통해 HTTP 요청을 보내는 데, 리소스가 없다는 것은 없으면 안되는 리소스에 대한 조회라고 생각하기 때문이다.