안녕하세요! 4개월차 신입 개발자 Kerry입니다!
오늘은 지난 프로젝트하면서 겪은 문제를 간단하게 회고하는 글을 써보려고 합니다.
개인적으로 회고하는 내용이라 많은 내용이 누락되고 틀릴 수 있으니 문제가 있으면 알려주시면 감사하겠습니다!
문제 상황
제가 겪은 상황을 간단하게 재현해봤습니다.
Kerry: 안녕하세요! 이번 프로젝트에서 이벤트 생성 작업을 수행하면서 특정 캘린더에 이벤트를 추가하는 기능을 구현했습니다. 이때, 캘린더 설정 값을 나타내는 Calendar Setting이 없는 경우에 대해 어떤 HTTP 상태 코드를 반환해야 할지 고민 중이었습니다.
사수: 좋은 질문이에요! 이러한 경우에는 404 Not Found 코드를 반환하는 것이 적절하지 않아요. 사용자나 프론트엔드 개발자는 "특정 calendar가 없다"라는 오해를 할 수 있습니다. 이 경우에는 400 Bad Request 코드를 반환하는 것이 더 적절합니다.
Kerry: 그렇군요. 하지만, 이유에 대해 좀 더 설명해주실 수 있을까요?
사수: 물론입니다! 404 Not Found 코드는 해당 리소스가 존재하지 않음을 나타내는 코드입니다. 하지만, 이 경우에는 리소스가 아니라 설정 값을 나타내는 것이기 때문에 사용자가 오해할 수 있습니다. 이러한 경우에는 400 Bad Request 코드를 반환하는 것이 더 적절합니다.
Kerry: 이해했습니다. 그러면 이러한 경우에 400 Bad Request 코드를 반환해야 합니다. 이 방법은 클라이언트에게 "calendar setting을 먼저 해주세요"라는 메시지를 반환하여, 오류가 발생한 원인을 명확하게 알릴 수 있게 됩니다.
사수: 맞습니다! HTTP 상태 코드를 사용하면 클라이언트와 서버 간의 원활한 통신을 보장할 수 있습니다. 궁금한 점이 있다면 언제든지 말씀해주세요!
400과 404에 대한 비교
결국 이 문제의 핵심은 400과 404를 쓰는 것에 대한 기준이 명확하지 않아서 생긴 문제입니다.
이번 문제를 계기로 저 만의 기준을 한 번 세워보려고 합니다.
그러기 위해 우선 400번과 404번을 비교해보겠습니다.
400 Bad Request
- 클라이언트 측에서 전송한 요청이 잘못된 경우 사용됩니다.
- 전송한 요청이 올바른 형식이 아니거나, 필수 값이 누락된 경우에도 사용됩니다.
- 서버는 클라이언트에게 오류 메시지를 반환하여, 오류가 발생한 원인을 명확하게 알릴 수 있습니다.
- 클라이언트가 전송한 데이터가 부적절하거나, 요청 자체가 유효하지 않은 경우에 사용됩니다.
이러한 경우에는 클라이언트가 요청을 수정하고 다시 시도하도록 유도합니다.
404 Not Found
- 클라이언트가 요청한 리소스가 존재하지 않는 경우 사용됩니다.
- 클라이언트가 요청한 URI에 해당하는 리소스가 없는 경우에 사용됩니다.
- 클라이언트는 다른 URI를 시도하거나, 해당 리소스가 삭제되었거나 이전되었을 가능성이 있습니다.
- 이러한 경우에는 클라이언트가 다른 URI를 시도하거나, 해당 리소스가 삭제되었거나 이전되었을 가능성이 있기 때문에, 오류가 발생한 원인을 확인해야 합니다.
결론
결국 이 둘의 핵심적인 차이 중 하나는 클라이언트의 행동을 유도해야하는가의 차이라고도 볼 수 있다. 만약 클라이언트의 행동을 교정해서 올바른 요청으로 만들 수 있다면 400을 내리는 게 좋은 선택입니다.
401과 403에 대한 비교
400번과 404번 다음으로 많이 쓰이고 헷갈리는 경우가 바로 이 401과 403인 경우입니다.
실제로 사용해보면 헷갈릴 일은 없지만 한번 정리해두고 가려고 합니다.
401 Unauthorized
- 클라이언트의 인증에 실패한 경우 사용됩니다.
- 요청한 리소스에 대한 인증 정보를 제공하지 않았거나, 제공한 인증 정보가 유효하지 않은 경우에 사용됩니다.
- 클라이언트는 올바른 인증 정보를 제공하거나, 로그인하도록 유도됩니다.
- 이러한 경우에는 클라이언트가 인증 정보를 수정하고 다시 시도하도록 유도합니다.
403 Forbidden
- 클라이언트의 요청이 거부된 경우 사용됩니다.
- 요청한 리소스에 대한 접근 권한이 없는 경우에 사용됩니다.
- 서버는 클라이언트에게 오류 메시지를 반환하여, 거부된 원인을 명확하게 알릴 수 있습니다.
- 클라이언트가 요청한 작업을 수행할 권한이 없는 경우에 사용됩니다.
- 이러한 경우에는 클라이언트가 권한을 얻거나, 요청한 작업을 수행할 권한이 있는 다른 계정으로 로그인해야 합니다.
결론
401은 "로그인부터 하고 오세요!" 이고 403은 "로그인 했는데 이거 사용할 권한이 없네요?" 인 경우다. 쉽게 얘기해서 로그인이 안됐으면 401! 로그인 됐는데 권한이 없으면 403!인 것이다!
최종 결론
| Status | 사용 기준 |
|---|---|
| 400 | 클라이언트가 잘못된 요청을 해서 제대로된 요청을 할 수 있도록 사용자를 유도해야할 경우에 사용하며, 유도해도 해결할 수 없는 경우, 다른 Status를 고려한다. |
| 404 | 클라이언트가 제대로 요청을 보냈는데 핵심 Resource가 없는 경우 사용한다. |
| 401 | 클라이언트가 로그인을 하지 않은 경우 |
| 403 | 클라이언트가 로그인 했는데 권한이 없는 경우 |
400 Bad Request
클라이언트가 서버에게 전송한 요청이 올바르지 않은 경우
- 예시: API를 호출하는 클라이언트가 전송한 요청 데이터의 필수값이 누락되었을 때, 서버는 400 Bad Request 코드를 반환하여 클라이언트에게 필수값이 누락되었음을 알립니다. 클라이언트는 이에 대한 수정을 하여 다시 요청을 보낼 수 있습니다.
클라이언트가 서버에게 전송한 요청 데이터가 올바르지 않은 경우
- 예시: API를 호출하는 클라이언트가 전송한 요청 데이터의 형식이 올바르지 않을 때, 서버는 400 Bad Request 코드를 반환하여 클라이언트에게 요청 데이터 형식이 올바르지 않음을 알립니다. 클라이언트는 이에 대한 수정을 하여 다시 요청을 보낼 수 있습니다.
404 Not Found
클라이언트가 요청한 리소스가 존재하지 않는 경우
- 예시: 웹 브라우저를 통해 존재하지 않는 페이지에 접속하려는 경우, 서버는 404 Not Found 코드를 반환하여 클라이언트에게 해당 페이지가 존재하지 않음을 알립니다. 클라이언트는 다른 페이지를 시도하거나, 존재하지 않는 페이지를 삭제 또는 이전했을 가능성이 있기 때문에 웹사이트 내부에서 조치를 취해야 합니다.
401 Unauthorized
클라이언트가 인증되지 않은 경우
- 예시: 사용자가 로그인하지 않고 회원전용 기능을 사용하려고 할 때, 서버는 401 Unauthorized 코드를 반환하여 클라이언트에게 로그인이 필요함을 알립니다. 클라이언트는 로그인을 하거나 인증 정보를 제공하여 다시 요청을 보내야 합니다.
403 Forbidden
클라이언트가 요청한 리소스에 접근할 권한이 없는 경우
- 예시: 사용자가 자신의 프로필 정보를 조회하려는데, 다른 사용자의 프로필 정보를 조회하려는 경우, 서버는 403 Forbidden 코드를 반환하여 클라이언트에게 권한이 없음을 알립니다. 클라이언트는 자신의 프로필 정보만 조회할 수 있도록 권한을 얻거나, 다른 계정으로 로그인해야 합니다.
저는 이번 기회에 4xx 번대 Status를 사용해야할 경우, 나만의 기준을 세웠습니다!
물론 모든 상황에 100% 적용할 수 있진 않지만 해당 Status를 사용해야할 경우, 의사결정이 한결 편하고 빨라질 것이기 때문에 매우 뿌듯하고 뜻 깊은 시간이였습니다!
부족한 글이지만 재미있으셨다면, 또 편하게 애기를 나누고 싶으시다면 아래의 커피챗 링크로 편하게 연락주세요!
Kerry Kim
Software Developer
📧 gimseoniin616@gmail.com
📱 010-8835-2870
☕ Kerry와의 커피챗
🏠 https://github.com/gimseonjin
