[HTTP] State Code

state code : 응답에서 Client가 보낸 요청의 처리 상태를 알려주는 기능

Client는 아래처럼 상위 상태코드로 해석해서 처리하면 됨

추후에 새로운 상태 코드가 추가되어도, Client는 변경하지 않아도 됨

---

*** 1xx : Informational. 요청이 수신되어 처리중

    --> 현재는 거의 사용되지 않음

---

*** 2xx : Successful. 요청 정상 처리

 

- 200 : OK

    ㄴ Client 요청을 성공적으로 처리 완료

 

- 201 : Created

    ㄴ Client 요청으로 서버에서 새로운 resource 생성

    ㄴ 생성된 resource는 응답의 Location Header 필드로 식별

        ex) Location : /members/100

 

- 202 : Accepted

    ㄴ 요청이 접수되었지만, 처리가 완료되지 않음

    ㄴ batch process와 같은 곳에서 사용됨

        ex) 요청 접수 후 1시간 뒤에 batch process가 요청을 한 번에 처리함

    --> 잘 사용하지는 않음

 

- 204 : No Content

    ㄴ 서버에서 성공적으로 요청 수행. 하지만, 응답 payload(전송 데이터) 본문에 보낼 데이터가 없음

        ex) 웹 문서 저장

            - 저장 버튼을 눌러도 어떠한 결과의 내용을 받지 않아도 되고, 저장만 해도 된다.

            - 또한 저장 버튼을 눌러도 같은 화면을 유지해야 한다.

    --> 결과 내용 없어도 204 message로 성공 여부 확인 가능

---

*** 3xx : Redirection. 요청을 완료하기 위해 추가 행동이 필요

Web Browser에서 3xx 응답의 결과에 Location Header가 있는 경우 --> Location 위치로 자동으로 이동(Redirect)

 

* Permanent Redirection (301, 308)

- resource의 URI가 영구적으로 이동한 경우

- 원래의 URL을 사용하지 않으며, 검색 엔진 등에서도 변경을 인지할 수 있음

 

- 301 : Moved Permanently

    ㄴ 특정 resource의 URI가 영구적으로 이동한 경우

        ex) /members --> /users

    ㄴ Redirect하는 경우, 요청 method가 GET으로 변하고, 본문이 제거될 수 있음

    --> 즉, POST로 요청했던 처음 데이터는 날라가고, 새로운 페이지의 입력 폼 화면을 GET으로 조회하는 것

    --> 사용자가 다시 입력해야 할 가능성이 높음

 

- 308 : Permanent Redirect

    ㄴ 결과 대신 캐시(기억)를 사용함

    ㄴ 301과 기능은 같지만, Redirect하는 경우, 요청 method와 본문은 유지한다

    ㄴ 301과 달리, POST 요청을 처음 보냈을 때, 데이터가 날라가지 않고  Redirect에서도 POST 요청을 유지함

 

- 실무에서 Redirect가 발생하면 페이지의 성격이 바뀌는 경우가 많아서, 안전하게 301을 사용해서 GET으로 돌리는 것을 선호함

- 그러나 데이터 손실 없이 주소만 옮기고 싶다면 308을 사용하면 됨

 

 

* Temporary Redirection (302, 307, 303)

resource의 URI가 일시적으로 변경 --> 따라서 검색 엔진 등에서 URL을 변경하면 안됨

 

- 302 : Found

    ㄴ Redirect하는 경우, 요청 method가 GET으로 변하고, 본문이 제거될 수 있음

- 303 : See Other

    ㄴ 302와 기능이 같음

    ㄴ Redirect하는 경우, 요청 method가 GET으로 변함

- 307 : Temporary Redirect

    ㄴ redirect하는 경우, 요청 메서드와 본문을 유지한다. (요청 method는 절때 변경하면 안됨)

 

PRG: Post/Redirect/Get

- POST로 주문 후에 Web Browser를 새로고침 --> 다시 요청하게 됨 --> 중복 주문 발생

        ex) 주문 완료 후에 주문 내역 화면으로 이동하는 경우

        --> 중복 주문 방지가 필요

- POST로 주문 후 주문 결과 화면을 GET method로 redirect를 하면 해결

    ㄴ 새로고침 해도 결과 화면을 GET으로 조회

    ㄴ 결국 중복 주문 대신에 결과 화면만 GET으로 다시 요청하기 때문에 중복 주문을 방지할 수 있다

- PRG 이후에 Redirect를 하는 경우, 이미 URL이 POST -> Get으로 Redirect 된 상태

--> 사용성이 좋으며, 서버 오류도 크게 줄어든다

 

* 사용은 어떤 것으로 해야하는가

- 처음 302는 HTTP method를 유지하는 것이 목표였으나, Web Browser는 대부분 GET으로 바꿔버림

    --> 모호한 302를 대신하여 명확한 303과 307이 등장함. (308도 301 대응으로 만들어짐)

- 303과 307를 선호하지만, 이미 많은 애플리케이션에서 302를 기본값으로 사용하고 있음

    --> 자동 Redirection을 할 때 GET으로 변해도 되는 경우 302를 사용해도 상관 없음

 

* 기타

- 300 : Multiple Choices (사용하지 않음)

- 304 : Not Modified

    ㄴ 캐시를 목적으로 사용함

    ㄴ Client에 resource가 수정되지 않음을 알려줌

    --> 이로서 Client는 로컬 PC에 저장된 캐시를 재사용한다. (캐시 Redirect)

    ㄴ 로컬 캐시를 사용해야하기 때문에, 응답에 message body를 포함하면 안된다.

    ㄴ 조건부 GET, HEAD 요청 시 사용

---

*** 4xx : Client Error. 잘못된 문법 등 서버에서 요청 수행 불가능

오류의 원인은 Client에 있기 때문에 이미 잘못된 데이터를 요청함

 

- 400 : Bad Request

    ㄴ 요청 구문, 메세지 등 오류

    ㄴ Client는 요청 내용을 다시 검토하고 보내야함

        ex) 요청 parameter가 잘못되거나, API 스펙이 맞지 않는 경우

 

- 401 : Unauthorized

    ㄴ Client가 해당 resource에 대한 인증이 필요함. 즉, 인증되지 않았다는 뜻

    ㄴ 401 오류 발생 시 응답에 WWW-Authenticate header와 함께 인증 방법을 설명함

 

- 403 : Forbidden

    ㄴ Server가 요청을 이해했지만, 승인을 거부

    ㄴ 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우에 발생

        ex) Admin 등급이 아닌 일반 사용자가 로그인한 경우 --> Admin 등급의 resource에 접근하는 경우 --> 승인 거부

 

- 404 : Not Found

    ㄴ 요청 resource를 찾을 수 없음. 즉, 요청 resource가 서버에 없는 경우 발생

    ㄴ Client가 권한이 부족한 resource에 접근 시, 해당 resource를 숨기고 싶을 때 사용

---

*** 5xx : Server Error : 정상적인 요청을 서버에서 처리하지 못함

Server 문제이기 때문에, 재시도 할 경우 복구 가능성이 있음

 

- 500 : Internal Server Error

    ㄴ Server 문제로 오류 발생한 경우이며, 애매한 오류인 경우엔 500으로 사용하면 됨

 

- 503 : Service Unavailable

    ㄴ Service 이용 불가

    ㄴ Server가 일싲거인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없는 경우에 사용

    --> Retry-After Header에 복구 예정 시간을 보낼 수 있음

 

 

 

* 5xx 에러를 되도록 사용하지 않아야 하는 이유

- 결제 및 주문 장애 :결제 요청 중 5xx 에러가 발생하는 경우, 사용자는 결제 여부를 알 수 없기 때문에 문의가 폭주하게 됨

    --> 매출 손실 발생

- 브랜드 가치 하락 : 잦은 서버 에러는 기술력이 부족한 서비스라고 인식됨

    ㄴ 금융권이나 결제 관련 서비스에서는 신뢰도에 치명타를 입을 수 있음

- 노이즈 발생 : 평소 사소한 로직 실수로 5xx 에러가 자주 발생하는 경우

    --> 진짜 서버가 터졌을 때 시스템이 보내는 알람을 무시할 수도 있음 (DB 다운, 네트워크 마비 등)

 

 

!! 실무에서는 5xx 에러를 0건을 유지하는 것을 목표로 해야한다.!!

 

* 4xx는 고객의 실수, 5xx는 나의 실수. 명심해야함