이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
그래서, 이게 가장 중요한 차이!!
- 400대는 클라이언트 요청 자체가 문제이기 때문에 복구가 불가능하다.
즉, 요청 자체를 수정해서 보내야 한다.- 500대 오류는 클라이언트가 나중에 똑같은 요청을 보내도, 성공할 가능성이 있다.
클라이언트는 요청을 재검토해서 다시 보내야 한다.
벡엔드 개발자들이 입구에서 이런 잘못된 요청들은 철저하게 막아야 한다.
그래야, 이 잘못이 클라이언트 잘못인지 인지를 시키고, 다시 요청을 보내게 하기 때문!!
로그인은 되는데, 접근 권한이 없는 경우이다.
즉, 인증은 됐지만, 인가가 안 된것
요청 페이지나 리소스가 없을 때
또는, 클라이언트가 접근할 수 없는 것을 요청하려고 할 때, 403으로 승인 거부 같은 에러 안 내고, " 이 페이지 없다!! "라고 완전히 숨기고 싶을 때
서버 측의 문제이기 때문에, 복구된 이후에 재시도하면, 요청이 성공할 수도 있다.
이름 그대로, 서버 내부의 문제!!
그래서, 애매한 서버 문제는 다 500으로 내보내면 된다.
미리 공지된, "서버 점검 시간"에 나오는 에러
혹은 "일시적인 과부하" 시에 나오는 에러
Retry-After 헤더에 얼마 뒤에 서버가 복구되는지 예상 시간을 보내줄 수도 있다.
그러나, 대부분의 이런 "서비스 이용 불가"는 예측 불가능하게 발생한다. 그래서, 504를 보는 경우는 생각보다 없고, 500이 떨어지는 경우가 많다.
400은 API 스펙이나 인증이 안 된 케이스가 가장 많다.
500은 서버 내부의 문제가 가장 많다.
서버에서 왠만하면 500대 에러는 만들면 안된다. 왜냐면, 진짜 서버에 문제가 터졌을 때, 500을 내보내야 한다.
ex)
API 스펙도 맞고, 서버로 성공적으로 들어왔다.
고객의 출금 요청에서 고객의 잔고에 부족하다면 이럴 때 500대 코드를 내면 안된다.
나이가 만 19세 이하인 사람이 19세 이상만 주문할 수 있는 것을 요청한다면, 500데 에러를 내면 안된다.
=> 이것은 비즈니스 로직상 "정상 프로세스"이다.
=> 그저 예외 케이스일 뿐
왜냐면, 500대 에러는 서버에 진짜 문제가 있을 때, 내야한다.
그래야 이제 보통 모니터링 툴에서 500 에러가 발생했을 때, 검사를 돌린다.
서버가 진짜 로직에 문제가 있어서 쿼리에 문제가 생기거나, DB가 내려가거나 이런 때에 500 대 에러를 내야한다.
나머지는 400이나 200으로 해결해야 한다.