HTTP 상태 코드 (404 error??)

 HTTP 상태 코드는 클라이언트가 보낸 요청에 대한 처리 결과를 알려주는 기능이다. HTTP 응답 메시지에서 status-code 역할을 한다. 이때 100 ~ 500 대 까지의 상태 코드가 사용된다. 그러면 모든 상태 코드의 뜻을 알아야 할까?? 101? 342? 254? 아니다. 상위 상태 코드로 해석해서 처리하면 된다. 다시 말하자면 2XX, 3XX, 4XX, 5XX 이렇게 몇백 번대의 상태

코드는 무엇을 의미한다라고 해석해도 된다. 

 상태 코드는 reason-phrase와 짝으로 많이 쓰인다. 매칭 되는 상태 코드와 reason-phrase를 설명하겠다.

 1XX (Informational)

 100번대의 상태 코드는 요청이 수신되어 처리중임을 나타낸다. 김영한님께서 백번대의 코드는 실무에서 한 번도 본 적이

없다고 하였으니 의미만 알아두고 넘어가자~

 

  2XX (Successful)

 200번대의 상태 코드는 클라이언트의 요청을 처리했다는 의미이다. 

• 200 OK - OK 메시지와 같이 쓰이는 200은 요청에 성공했음을 의미한다. 보통 GET으로 클라이언트의 요청이 일어났을 때의 응답으로 쓰인다
• 201 Created - 201은 요청에 의해 새로운 리소스가 생성 되었음을 의미한다. 예를 들면 PUT으로 회원 정보를 새로 등록할 때 성공적으로 진행되었을 경우 사용한다.
• 202 Accepted - 요청이 성공적으로 되었으나 처리가 완료되지 않은 경우 사용한다. 처리가 일어나지 않은 부분은 오류가 아니라 몇 시간 뒤에 요청을 처리하도록 설계된 경우이다. 예약을 하는 개념으로 접수가 성공적으로 된 것을 의미한다.
• 204 No Content - 요청이 성공적으로 수행되었고 응답 메시지에 message body 부분에 보낼 데이터가 없을 경우 사용한다.
  예시로 문서 편집기에서 save 버튼을 눌렀을 경우이다. 우리가 한글 파일에서 작업을 할 때 중간중간 저장을 한다. 이때마다 메시지가 나올 필요는 없다. 이럴 때 사용한다.

 3XX (Redirection)

 300번대는 요청을 완료하기 위해 추가적인 행동이 필요하다는 것을 의미한다. Redirection은 다시 연결한다고 이해하면 된다. 3xx 응답에는 location 헤더를 포함하는게 일반적인데 이때 location 위치로 자동으로 이동하는 것이 redirect이다.

url을 변경하는 것이다.

redirection 설명

 리다이렉션은 영구, 일시, 특수 리다이렉션으로 나눌 수 있다.

 영구 리다이렉션 

 말 그대로 리소스의 URI가 영구적으로 이동한다. 원래 URI는 사용하지 않는다. 

• 301 Moved Permanently - 리다이렉트시 클라이언트의 요청 메서드가 GET으로 그리고 본문이 제거될 수(?)도 있다.
  (? 에 대한 내용은 나중에 설명)
• 308 Permanent Redirect - 301과 기능은 같으나 메서드와 본문을 유지한다. URI만 변경한다.

 영구 리다이렉션을 사용할 때는 대부분 301 리다이렉션을 사용한다. 왜냐하면 리다이렉션이 일어나야 할 경우에는 어차피 내부적으로 전달해야 하는 내용도 다 바뀌기 때문에 굳이 메시지를 유지할 필요가 없으므로 301을 사용한다고 한다.

 하지만 리다이렉션은 실무에서 보통 일시적 리다이렉션을 사용한다고 한다.

 일시적인 리다이렉션

 URI가 일시적으로만 변경되는 것이다. 나중에는 기존의 URI를 사용한다.

• 302 Found - 리다이렉트 요청 시 메서드가 GET으로 그리고 본문이 제거될 수(?) 있다. (역시 ?에 대한 설명은 뒤에) 제거될 수 도 있다 했지만 대부분 GET으로 변한다고 한다. 
• 307 Temporary Redirect - 302와 기능은 같으나 메서드와 본문을 유지한다.
• 303 See Other - 302와 기능은 같으나 메서드를 GET으로 변경해야만 한다.

 리다이렉션에는 PRG 패턴이 있다. 정~말 실무에서 유용한 패턴이라고 한다. POST로 온 요청 메서드를 Redirect를 할 때 GET으로 바꾸는 패턴이다. (Post -> Redirection -> Get) 상품 주문 예시로 설명을 하자면 고객이 상품을 주문하였다.

 이때 클라이언트에서 주문 정보를 서버에 등록할 것이다. 등록이므로 Post 메서드를 사용해서 메시지를 보내고 서버에서 2XX와 함께 요청을 처리했다는 메시지를 보낸다. 이때 고객이 새로 고침 버튼을 누르면??? 제일 마지막에 했던 행동을 다시 반복한다. 그러면 새로 고침을 할 때마다 주문이 계속 서버에 등록된다. PRG를 사용하면 고객이 주문 정보를 Post한 후 서버에서 2XX이 아닌 3XX redirection 메시지를 보내고 URI를 주문 결과를 확인할 수 있게 바꾸고 메서드를 Get으로 바꾼다. 이러면?? 고객이 새로 고침을 해도 주문 정보가 Post되는 것이 아닌 주문 결과를 Get 할 수 있게 된다~ PRG 패턴은 클라

입장에서 사용성이 좋고 서버 입장에서는 불필요한 오류가 줄어든다. 기똥차다 기똥차

 

 그래서 솔직히 다 거기서 거기인 것 같은데 redirection이 필요한 경우 상태 코드는 어떤 것을 쓰는게 좋을까?

 위에서 될 수(?)도 있다고 설명한 상태 코드들은 사실 스펙을 정의할 때 메서드를 유지하도록 의도해서 만들어 졌다. 하지만 스펙에 세세히 설명해 놓지 않아서 개발자들이 대부분 메서드를 GET으로 바꾸어 버렸다. 결과적으로 302 코드는 바뀔 수도? 안 바뀔 수도? 있는 상태 코드가 되어버렸고 이러한 애매한 부분을 해결하기 위해 바뀌면 안 되는, 바뀌어야 하는 307, 303이 등장하였다. 그래서 307, 303을 권장하지만 이미 많은 애플리케이션들이 302를 기본 값으로 사용하고 있다. 

 4XX (Client Error)

오류의 원인이 클라이언트에 있다. 오류의 원인이 클라이언트에 있기에 재시도를 하여도 문제가 해결될 수 없다!!

• 400 Bad Request - 요청을 잘못한 상황이다. 클라이언트가 내용을 수정해서 보내야 한다. ex) 요청 파라미터가 잘못 되었거나 API 스펙이 맞지 않은 경우
• 401 Unauthorized - Unauthorized(인가되지 않음) 보다는 Unauthentication(인증되지 않음)으로 이해하는 것이 좋다. 인가는 인증은 되었지만 해당 리소스에 접근할 권한이 없음을 나타내지만 401을 사용하는 상황은 로그인이 되지 않은 경우처럼 인증되지 않은 상황에 사용된다.
• 403 Forbidden - 403을 Unauthorized로 이해하면 쉽다. 인증은 되었지만 접근 자격이 없는 경우 사용된다.
• 404 Not Found - 우리가 가장 많이 봤을 코드이다. 요청 리소스가 서버에 없거나 그냥 해당 클라이언트한테 숨기고 싶을때 그런 거 없어~라고 표현하기 위해 사용된다. 그냥 숨기고 싶을 때 사용할 수도 있다는 거... 좀 충격인데?

 5XX (Server Error)

서버에 문제가 있을 때 사용한다. 서버 문제이기에 사용자가 같은 자원으로 재시도해서 문제가 해결될수도 있다.

 500번대 에러는 남용하면 안되고 정말 온전히 서버에 오류로 발생한 경우일 때만 사용하자.

• 500 Internal Server Error - 서버 내부 문제로 발생한 오류일 때 사용한다. 그냥 애매하면 500 쓰면 된다.
• 503 Service Unavailable - 일시적으로 서비스를 이용할 수 없을 때 사용한다. 일시적 과부하, 유지 보수 작업이 예정되어 있을 때 사용한다. Retry-After 헤더 필드에 복구되는 시점을 알 수 있다.

 

 여기까지 설명이고 최근에 알게 된것이 저번에 포스트 한 HTTP 메서드와 지금 작성한 상태 코드도 그렇고 여태까지 PUT을 사용하면 알아서 척척척 작동하는 줄 알았다. 알고 보니 PUT을 사용해도 다른 작업이 일어날 수 있다. 5XX 번대 상태 코드가 와도 2XX의 기능을 사용하게 개발할 수 있다. 이것 모두 규약? 약속?이다. 나 혼자 개발하고 유지 보수 하는 것도 아니고 나만 사용하는 서비스를 만드는 것이 아니라 서버 에러가 있으면? 5XX 상태 코드를 보내자, 회원 등록할 때는? PUT을 사용하자 이런 약속일뿐이다. PUT 했다고 알아서 동작하는 것이 아니라 그에 맞는 기능은 따로 구현을 해서 매칭을 해주어야 하는 것이다. 그니까 이게 무슨 말이냐면? 할 일이 더 많다는 거지,,

 

https://inf.run/QTy9

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의