HTTP STATUS 204 vs 404

과거에 해당 부분에 대해서 팀 내 논의가 있어 해당 내용을 간략하게 정리하고 공유하고자 합니다.

 

팀 내 진행되는 프로젝트에선 API 컨벤션 및 협업과 관련된 컨벤션 논의가 활발하게 이뤄지지 않은 상태였습니다.

그렇기 때문에 과거 정리해둔 글을 기반으로 회고하고 생각을 나누기 위해 글을 정리했습니다. 해당 아래의 내용은 과거의 내용입니다

 

 

당시 팀 내 진행되는 프로젝트에선 객체 조회 시 객체가 존재하지 않으면 정의된 예외를 발생하고 예외 핸들러를 통해 HttpStatus를 404로 전달하고 있었습니다.

 

주로 200Status 는 성공을 의미하는, 400번대는 잘못된 요처에 관한 내용을 담고 있기에 HttpStatus에 관한 나름의? 규칙을 준수하고 있다고 생각하고 있었습니다.

 

그러나 오늘 문득 코드를 작성하는데 기존에 404로 정의해놓은 Status가 204로 바뀌어 있는 것을 확인했고, 바꾼 결정을 한 팀원분과 이야기를 나눴습니다. 

 

해당 내용은  회사의 컨벤션마다 조금씩 견해가 다르고, 개발자 커뮤니티인 Stack OverFlow에서도 뜨끈뜨끈한 논쟁거리가 되곤 했습니다. 이번 기회를 통해 팀 내 컨벤션을 조금 더 정립하고, 팀 개발자와 이야기 하면서 의견이 갈려 204와 404에 관한 기준을 세우고 정리하고자 합니다.

 

레퍼런스를 찾아보기 전 팀에 계시는 선임 연구원님께 먼저 물어본 대답입니다. (정리: 선택적 사용)

 

 

예를 들어 A라는 기능에 여러 데이터를 찾는 경우가 있다고 가정해보겠습니다.

일반적으로 JPA 기준으로 코드를 작성하게 된다면 아래와 같은 형태로 비슷하게 작성될 것입니다.

Car car = carRepository.findById(reservation.getExport().getCarId())
			.orElseThrow(() -> new DefinedException(VehicleErrorCode.CAR_NOT_EXIST));

 

 

간략하게 설명을 하자면 다음과 같습니다.

 

1. 전달된 차량 식별자를 이용해 데이터베이스에서 조회, 만약에 해당 객체가 존재하지 않으면 커스텀 예외 발생

2. 정의된 커스텀 예외는 발생하고, 이를 예외 핸들러가 잡아서 최종적으로 응답 리턴

 

 

사실 어떤 코드를 응답으로 리턴하더라도 크게 이슈가 생길 것 같지는 않습니다.

그러나 조금 더 http의 규격에 맞게 코드를 작성하고 어떤 상황에 대해 기준이 존재하지 않으면 계속 혼란에 빠질 것이라 생각했습니다.

 

이는 클라이언트와 서버간의 통신 상태를 나타내는 약속이기에 지켜지는게 맞다고 생각했습니다.

문제는 간단하게 설명했고, 204와 404에 대해 검색해 찾은 레퍼런스를 정리해보겠습니다.

---

일단 먼저 Http Status code 204가 무엇이냐?

• 상태 : 204 No Content

The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response content. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.

간략하게 설명하자면 “요청은 성공했으나 응답에 추가로 보낼 데이터가 없음”을 나타냅니다.

---

Http Status code 404는?

• 상태 : 404 Not Found

The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.

간략하게 설명하자면 “서버가 요청받은 리소스를 찾을 수 없음"을 의미합니다.

출처 :

204 No Content - HTTP | MDN

RFC 9110: HTTP Semantics

---

그럼 204와 404가 어떤 상태코드인지 알았으니 여러 케이스를 통해 어떤 상황에 사용해야 적절한지 고민해보는 것이 좋을 것 같습니다.

 

데이터가 없을 수도 있는 상황 vs 데이터가 없으면 안 되는 상황

예를 들어 유저 목록을 조회하는 API가 있다 가정해보겠습니다.

Get요청으로 목록을 조회할 것이고, 데이터는 존재하지 않습니다
(존재할 수도, 존재하지 않을수도 있는 상황 → 데이터의 존재가 필수는 아닌 상황이다 )

현 상황에서는 데이터가 존재하지 않는 것이지, 에러가 발생한 것이 아닙니다.

데이터가 없는 상황이 정상인 상황이다 (유저가 없다면 유저데이터가 없는 것이 정상이니까?)

204와 404의 논의는 데이터가 없는 것이 정상인 상황과 없으면 에러인 상황에 관한 구분이 명확해야한다.

여기서 없을 수 있는 이라는 키워드는 GET 메서드를 보내는 경우 없는 리소스에 대해 파라미터로 요청하는 경우를 뜻한다.

해당 요청을 정상으로 수행했지만, 서버에는 해당 파라미터와 일치하는 데이터가 없어 빈 페이로드를 200과 함께 반환한다.

없으면 안 되는 키워드는 PUT이나 PATCH, DELETE에 해당한다.

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

HTTP STATUS CODE 204의 사용처에 관한 예시

 

주로 204는 요청은 성공했지만 응답 컨텐츠가 없음을 나타냅니다.

• 주로 PUT과 DELETE요청
  • (데이터를 넣거나, 삭제할 때 굳이 응답값을 줄 필요가 없으니까?라는것이 저의 개인적인 의견입니다)
• 예시
  • 요청이 정상으로 처리 되었지만 응답 데이터를 반환할 필요가 없는 경우(업데이트 및 데이터 삭제)
  • HEAD 요청

HTTP STATUS CODE 404의 사용처 예시는 다음과 같습니다

 

주로 404는 요청한 리소스가 서버에서 찾을 수 없음을 나타냅니다.

• 주로 GET요청
  • (데이터를 요청했지만 요청한 데이터가 없으니 404를 내려준다?)

• 결론적으로는 '데이터 없음'과 '404 Not Found'를 같은 용도로 사용하면 안 된다.

200: OK (정상, 데이터 있음)
204: No Contents (정상, 데이터 없음)
301: Moved Permanently (리다이렉션)
400: Bad Request (실패, 클라이언트에서 넘어온 파라미터가 이상함)
401: Unauthorized (실패, 클라이언트에서 넘어온 보안 토큰이 이상함)
403: Forbidden (실패, 사용자의 권한으로 리소스를 사용할 수 없음)
404: Not Found (실패, 데이터가 있어야 하나 없음)
410: Gone (실패, 데이터가 있었으나 삭제됨. 이건 굳이...?)
500: Internal Server Error (실패, 서버 로직 문제)
501: Not Implemented (실패, 없는 리소스 요청)

 

출처 및 참고 레퍼런스 : 상태 코드, 뭘 줘야할까?

상태 코드, 뭘 줘야할까?