이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.

---

4XX - 클라이언트 오류

• 400대 오류와 500대 오류를 가르는 중요한 차이
  • 400대는 클라이언트가 잘못 요청을 한거다. 그래서, 똑같이 여러 번 재시도해도, 계속 실패한다.
  • 그런데, 500대 오류는 예를 들어서, 서버 DB에 장애가 났다면?
    그 때, 서버에 요청을 보내면, 500대 오류가 날 것이다. 그런데, 나중에 DB가 복구가 된 다음에, 클라이언트에서 요청을 재시도하면... 요청이 성공할 가능성이 있다.

그래서, 이게 가장 중요한 차이!!

• 400대는 클라이언트 요청 자체가 문제이기 때문에 복구가 불가능하다.
  즉, 요청 자체를 수정해서 보내야 한다.
  
• 500대 오류는 클라이언트가 나중에 똑같은 요청을 보내도, 성공할 가능성이 있다.

400 Bad Request

클라이언트는 요청을 재검토해서 다시 보내야 한다.

벡엔드 개발자들이 입구에서 이런 잘못된 요청들은 철저하게 막아야 한다.

그래야, 이 잘못이 클라이언트 잘못인지 인지를 시키고, 다시 요청을 보내게 하기 때문!!

401 Unauthorized

• 인증 ( Authentication )
  • 인증이 안되면, 로그인 자체가 안된다.
• 인가 ( Authorization )
  • 로그인 한 사람이 접근할 수 있는 권한
  • 특정 리소스에 대해서 접근할 수 있는지에 대한 권한

403 Forbidden

로그인은 되는데, 접근 권한이 없는 경우이다.
즉, 인증은 됐지만, 인가가 안 된것

404 Not Found

• 요청 페이지나 리소스가 없을 때

• 또는, 클라이언트가 접근할 수 없는 것을 요청하려고 할 때, 403으로 승인 거부 같은 에러 안 내고, " 이 페이지 없다!! "라고 완전히 숨기고 싶을 때

---

5XX (Server Error)

서버 측의 문제이기 때문에, 복구된 이후에 재시도하면, 요청이 성공할 수도 있다.

500 Internal Server Error

이름 그대로, 서버 내부의 문제!!

그래서, 애매한 서버 문제는 다 500으로 내보내면 된다.

503 Service Unavailable

미리 공지된, "서버 점검 시간"에 나오는 에러

혹은 "일시적인 과부하" 시에 나오는 에러

Retry-After 헤더에 얼마 뒤에 서버가 복구되는지 예상 시간을 보내줄 수도 있다.

그러나, 대부분의 이런 "서비스 이용 불가"는 예측 불가능하게 발생한다. 그래서, 504를 보는 경우는 생각보다 없고, 500이 떨어지는 경우가 많다.

---

400과 500에서 가장 많이 나는 에러

400은 API 스펙이나 인증이 안 된 케이스가 가장 많다.

500은 서버 내부의 문제가 가장 많다.

5XX 상태 코드를 함부로 남발하면 안되는 이유

서버에서 왠만하면 500대 에러는 만들면 안된다. 왜냐면, 진짜 서버에 문제가 터졌을 때, 500을 내보내야 한다.

ex)
API 스펙도 맞고, 서버로 성공적으로 들어왔다.
고객의 출금 요청에서 고객의 잔고에 부족하다면 이럴 때 500대 코드를 내면 안된다.

나이가 만 19세 이하인 사람이 19세 이상만 주문할 수 있는 것을 요청한다면, 500데 에러를 내면 안된다.
=> 이것은 비즈니스 로직상 "정상 프로세스"이다.
=> 그저 예외 케이스일 뿐

왜냐면, 500대 에러는 서버에 진짜 문제가 있을 때, 내야한다.
그래야 이제 보통 모니터링 툴에서 500 에러가 발생했을 때, 검사를 돌린다.

서버가 진짜 로직에 문제가 있어서 쿼리에 문제가 생기거나, DB가 내려가거나 이런 때에 500 대 에러를 내야한다.

나머지는 400이나 200으로 해결해야 한다.