400 or 403

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status 400은, 요청 헤더나 본문 등 페이로드에 문제가 있을 때 적절한 것 같고, 403은 인증한 클라이언트가 누군지는 알지만 넌 안됨이라고 뱉을 때 적절한 것이니, 둘 다 애매하긴 매한가지인 것 같습니다. 차라리 503 Service Unavailable이 "장애나 점검으로 인한 서비스 불가"라는 점에서 "점검" 쯤으로 여겨도 될 것 같습니다만, 역시 딱 이거다 하기는 아쉽긴 하네요. 4xx대를 노리시는 것 보니, "이 시간엔 쓰면 안되는 API야"라는 점을 클라이언트가 어겼다는 점을 중점적으로 보시는 것 같은데요, 그렇다면 사실 약속에 의하면 정상적인 요청이 들어오는 경우가 아닌, 예외 상황인 거므로, 사실 그렇게 심각하게 고민하지 않아도 된다고 봅니다. 403은 확실히 아니니까, 400쯤으로 해도 되고, 아니면 아예 4xx쯤에서 안쓰는 거 내가 정해서 써도 됩니다. 암튼, HTTP 상태코드가 딱 안떨어지는 경우가 더러 있는데, 사실 뭐가 딱 맞다라고 주장하기 어려운 경우가 많아서, 주도권(책임) 있는 사람이 뭐하나 일관되게 정하고 우기면 되는 경우가 많습니다. 뭐가 맞네 싸울 여지를 안남기는게 중요해요. 쓸데없는 논쟁으로 시간낭비 되면 아깝잖아요.

http 상태코드로 관리하신다면 503 상태 코드가 적합할 것 같습니다! 다만 특정 시간대에만 호출이 가능함을 상태코드로만 처리하면 통상 503은 일시적 장애로 인지하기 때문에 정확한 에러 원인 추적이 어려울 수 있을 것 같은데요! 실제로 503 상태 코드가 발생할 사례랑 중첩되는 경우가 발생할 수 있으니 http 상태 코드랑은 별개로 요청을 처리할 수 있는 시간대가 아니라고 응답 파라미터에 에러 코드, 에러 메세지를 별도로 추가하여 내부적으로 에러 코드 정책을 추가하는 방향은 어떠실까요? 아래는 REST API 설계에 대해 좋은 글을 커리어리로 공유받았던 기억이 있어 공유드립니다 https://newsletter.techworld-with-milan.com/p/rest-api-design-best-practices 아래는 카카오 쇼핑 오픈 API의 상태 코드 정책인데 참고하시면 좋을 것 같습니다 https://shopping-developers.kakao.com/hc/ko/articles/4578818403343-응답-코드-및-에러-코드