HTTP 상태코드, HTTP 상태코드 소개, 2xx - 성공, 3xx - 리다이렉션, 4xx - 클라이언트오류, 5xx - 서버오류

  출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본 지식(유료) / 김영한님

  유료 강의이므로 정리에 초점을 두고 코드는 일부만 인용  

https://inf.run/8ZEU8

---

1. HTTP 상태코드 - 소개

1) 상태 코드

(1) 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

• 1xx (informational) : 요청이 수신되어 처리중, 거의 사용하지 않으므로 설명 생략
• 2xx (Successful) : 요청 정상 처리
• 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함

(2) 만약 모르는 상태 코드나 미래의 새로운 상태 코드가 나온다면?

• 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면 클라이언트가 상위 상태코드로 해석해서 처리함
• 새로운 상태 코드가 추가 되어도 클라이언트를 변경하지 않아도 됨(물론, 미래에 새로운 상태코드를 반영하도록 클라이언트를 패치하면 더 좋음)
• 299 ??? -> 2xx (Successful)
• 451 ??? -> 4xx (Client Error)

---

2. 2xx - 성공

1) 클라이언트의 요청을 성공적으로 처리

(1) 200 - OK

• 요청 성공
• 가장 많이 보는 케이스

(2) 201 - Created

• 요청이 성공하여 새로운 리소스가 생성됨(POST 같은 경우)

(2) 202 - Accepted,(잘 사용하지 않음)

• 요청이 접수 되었으나 처리가 완료되지 않았음
• 배치 처리 같은 곳에서 사용(요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우)

(3) 204 - No Content

• 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
• 결과 내용이 없어도 204 메시지만으로 성공을 인식할 수 있음
• 예) - 웹 문서 편집기에서 save버튼을 눌러도 같은 화면을 유지해야 하는경우

** 참고

• 그 외에도 많은 상태 코드가 있지만 모든 상태코드를 다 사용하는 것이 좋은 것은 아님
• 실제 개발 시 어느정도 사용할 범위를 잡고 개발에 착수를 함

---

3. 3xx - 리다이렉션

1) 리다이렉션 이해

• 요청을 완료하기 위해 유저 에이전트(클라이언트 프로그램)의 추가 조치가 필요함
• 웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 Location 위치로 자동으로 이동함(리다이렉트)

(1) 자동 리다이렉트 흐름

• 종료된 이벤트 페이지가 /event, 새로운 이벤트 페이지가  /new-event로 변경 되었다고 가정
• 종료된 /event 경로로 접속을 하면 서버가 301 상태로 Location에 새로운경로(/new-event로 설정)를 적어서 응답하면 웹브라우저가 Location에 적인 경로로 다시 서버에 요청하고 해당 경로에 접속됨
• 처리 프로세스가 매우 빨라서 클라이언트 입장에선 거의 못느낌

(2) 리다이렉션의 종류

• 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동(/event -> /new-event)
• 일시 리다이렉션 - 일시적인 변경 (주문 완료 후 주문 내역 화면으로 이동)
• 특수 리다이렉션 - 결과 대신 캐시를 사용

2) 영구 리다이렉션

• 301(간혹사용)
• 308(거의 사용하지 않음)
• 리소스의 URI가 영구적으로 이동하여 원래의 URL을 사용이 불가함(검색 엔진 등에서도 변경을 인지)

(1) 301 - Moved Permanently

• 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거 될 수 있음(MAY)
• 리다이렉트가 진행 되면 서버는 GET으로 요청을 받기 때문에 해당 URI의 초기상태를 반환함
• 최초에 요청했던 데이터를 클라이언트가 다시 작성해서 전송 해야 함
• 처음에 의도할 때에는 본문을 유지하는 것으로 만들었지만 웹 브라우저들이 모두 GET으로 리다이렉트가되어 HTTP 스펙 자체를 변경한 케이스

(2) 308 - Permanent Redirect

• 301과 기능은 같지만 리다이렉트 요청시 메서드와 본문을 유지(처음 요청이 POST -> 리다이렉트도 POST)
• 처음 보낸 요청이 살아 있어 응답 시 해당 요청을 처리한 응답을 보내 편리하다고 생각 될 수 있지만 실무에서는 POST로 요청이 와도 리다이렉트는 GET으로 돌리는것이 맞음
• 보통 리다이렉트로 URI가 바뀌는 상황이라면 비즈니스 내부적으로 전달해야하는 데이터가 다 변경되기 때문에 기존 데이터를 유지할 필요가 없음

좌) 301 / 우) 308

3) 일시적인 리다이렉션(많이 사용)

• 302, 307, 303
• 리소스의 URI가 일시적으로 변경됨, 검색 엔진 등에서 URL을 변경하면 안됨

(1) 302 - Found

• 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거 될 수 있음(301과 동일 케이스)
• 명시적이진 않지만 실무에서 대부분 302을 사용하며 메서드도 대부분 GET으로 변해서 리다이렉트됨

(2) 307 - Temporary Redirect

• 302와 기능은 같고 리다이렉트시 요청 메서드와 본문 유지 즉, 요청 메서드를 변경하면 안됨

(3) 303 - See Other

• 302와 기능은 같고 리다이렉트시 요청 메서드가 무조건 GET으로 변경됨

(4) 일시적인 리다이렉션 예시 - PRG: Post/Redirect/Get

• POST로 주문 후 새로 고침(다시요청)하면 중복 주문이 될 수 있음
• 원칙적으론 서버에서도 당연히 막아야 하고, 클라이언트에서도 리다이렉트 Post/Redirect/Get 패턴으로 이중으로 방지 할 수 있음
• 새로고침을 해도 결과 화면을 GET으로 조회하도록 하여 중복 주문이 방지됨

(5) PRG 사용 전/후 차이

• PRG를 사용 전에는 서버에서 응답메시지를 200으로 내려 새로고침을 하면 주문데이터가 서버로 전송되어버리기 때문에 중복 주문이 발생함
• PRG를 사용하면 최초 요청 시 Location정보를 담아(주문 번호 등) 302로 응답을 내려서 GET으로 자동 리다이렉트가 되도록 설계
• 응답된 Location 정보로 리다이렉트를 GET으로 서버에 요청하면 서버는 주문정보를 조회해서 페이지만 반환
• 결과 화면에서 새로고침을 해도 GET(조회 - 결과화면)만 반환됨

좌) PRG 사용 전 / 우) PRG 사용 후

(6) 정리 - 무엇을 사용할까?

• 처음 302 스펙의 의도는 HTTP메서드를 유지하는 것이였으나 웹 브라우저들이 대부분 GET으로 바꾸어 버려서 모호한 302을 대신하는 명확한 307, 303이 등장하였음(301 대응으로 308도 등장)
• 그러나 307, 303을 권장하지만 많은 프레임워크나 애플리케이션 라이브러리들이 302를 기본값으로 사용중이여서 실무에서 302을 많이 사용함
• 자동 리다이렉션 시 GET으로 변해도 되면 302를 사용하여도 큰 문제가 없음

4) 기타 리다이렉션

(1) 300 - Multiple Choices

• 사용안함

(2) 304 - Not Modified(캐시에서 자세히 설명, 굉장히 많이 씀)

• 캐시를 목적으로 사용
• 클라이언트에게 리소스가 수정되지 않았음을 알려주면 클라이언트는 로컬 PC에 저장된 캐시를 재사용
• 캐시로 리다이렉트 하기 때문에(로컬 캐시를 사용해야 하기 때문에) 응답에 메시지 바디를 포함하지 않음
• 조건부 GET, HEAD 요청시 사용

---

4. 4xx - 클라이언트 오류, 5xx - 서버 오류

1) 4xx - 클라이언트 오류

• 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 오류의 원인이 클라이언트에 있음
• 중요! 즉, 클라이언트가 이미 잘못된 요청데이터를 보내고 있어서 똑같은 재시도를 해도 계속 실패함

(1) 400 - Bad Request

• 클라이언트의 잘못된 요청으로 서버가 요청을 처리할 수 없음
• 요청 구문, 메시지 등의 오류
• 예) - 요청 파라미터가 잘못되었거나 API 스펙이 맞지 않을 때 등

(2) 401 - Unauthorized

• 인증(Authentication) 되지 않음
• 401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
• 오류 메시지가 인가(권한)이 없다는 뜻이지만 실제로는 인증자체가 되지 않았다는 뜻

** 참고

• 인증(Authentication) : 본인이 누구인지 확인(로그인 같은 것)
• 인가(Authorization) :  권한 부여(ADMIN 권한 처럼 특정 리소스에 접근할 수 있는 권한. 인증 후 인가가 있음)

(3) 403 - Forbidden

• 서버가 요청을 이해했지만 승인을 거부함
• 주로 인증 자격 증명은 했지만 접근 권한이 불층분한 경우
• 예) - 관리자 권한이 아닌 사용자가 로그인은 했지만 관리자 등급의 리소스에 접근 하는 경우 등

(4) 404 Not Found

• 요청 리소스가 서버에 없거나 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

2) 5xx - 서버 오류

• 오류의 원인이 서버에 있기 때문에 재시도 하면 성공 할 수도 있음(서버가 복구 되는 등 여러가지 이유로..)
• 서버에서의 에러(5xx 에러)는 진짜 서버에 문제가 있을 때에만 내려야 함

(1) 500 - Internal Server Error

• 서버 문제로 오류가 발생
• 서버에서 발생한 오류는 애매하면 500 오류로 내리면 됨

(2) 503 - Service Unavailable

• 서비스 이용 불가
• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리 할 수 없는 경우(서버점검, 서버 다운)
• Retry-After 헤더 필드로 얼마뒤에 복구되는지 정보를 보낼 수 있음