클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
- 1xx(Informational) : 요청이 수신되어 처리 중
- 2xx(Successful) : 요청 정상 처리
- 3xx(Redirection) : 요청을 완료하려면 추가 행동이 필요
- 4xx(Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음.
- 5xx(Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함
클라이언트 입장에서 인식할 수 없는 상태 코드를 서버가 반환할 경우 클라이언트는 상위 상태 코드로 해석해서 처리한다. 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.
만약 상태 코드 299 ??? 이 온다고 해도 2xx이기 때문에 Successful이라고 생각하면 된다.
다른 상태 코드에 대해서는 상세히 알아보지만 1XX(Informational)은 거의 사용하지 않기 때문에 생략한다.
클라이언트의 요청을 성공적으로 처리했을 때의 상태 코드이다.
가장 많이 보는 응답 메시지로 GET과 같은 조회 요청에 대해 성공적으로 요청을 받아서 결과를 잘 처리해서 응답을 할 경우 해당 상태 코드를 반환한다.
요청이 접수되었으나 처리가 완료되지 않은 경우로 배치 처리 같은 곳에서 사용한다. 예를 들어 요청 접수 후 1시간 뒤 배치 프로세스를 실행하라는 요청의 경우를 말한다.
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없는 경우 예를 들어, 웹 문서 편집기에서 저장 버튼을 눌렀을 경우 그 요청에 결과로 딱히 어떤 응답이 필요하지는 않다. 결과 내용이 없어도 204 메시지만으로 성공을 인식하기만 하면 된다.
-
요청을 완료하기 위해 유저 에이전트의 추가 조치가 필요한 경우
-
웹 브라우저는 3xx 응답 결과에 Location 헤더가 있는 겨우 Location 위치로 자동 이동한다. (리다이렉트)
- 예) /members → /users
- 예) /event → /new-event
- 주문 완료 후 주문 내역 화면으로 이동
- PRG : POST/Redirect/Get
- 결과 대신 캐시를 사용
- 리소스의 URI가 영구적으로 이동
- 원래의 URL를 사용하지 않는다. 검색 엔진 등에서도 변경 인지
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. (MAY)
- 301과 기능은 같다.
- 리다이렉트시 요청 메서드와 본문 유지 (처음 POST를 보내면 리다이렉트도 POST로 유지)
💡 실무에서는 경로가 바뀌면서 리다이렉션하는 경우 웬만해서는 POST 사용을 유지할 필요가 없다. 페이지가 바뀌면서 필요한 파라미터나 정보들도 바뀌기 때문이다 그렇기에 대부분 308보다는 301을 사용한다.
- 리소스의 URI가 일시적으로 변경
- 따라서 검색 엔진 등에서 URL을 변경하면 안 된다.
- 세 가지의 기능은 거의 동일하다.
-
302 Found
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. (MAY)
-
307 Temporary Redirect
- 302와 기능은 같다. 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안 된다. MUST NOT)
-
303 See Other
- 302와 기능은 같다.
- 리다이렉트시 요청 메서드가 GET으로 변경된다.
일시적인 리다이렉션
만약 POST로 주문 후에 웹 브라우저를 새로고침하면 어떻게 될까? 양식을 다시 보내겠냐며 경고 창이 뜰 수 있지만, 다시 요청할 경우 중복으로 주문이 들어갈 수 있다.
주문 완료 상황에서 새로고침을 하면 다시 POST 요청이 가면서 주문이 중복된다. 어떻게 방지할 수 있을까?
- POST로 주문 후, 주문 결과 화면을 GET 메서드로 리다이렉트
- 새로고침 시, 결과 화면을 GET으로 조회
위 과정과 비슷해 보이지만 최초 주문 시 응답의 상태 코드가 200이 아닌 302이다. 그럼 클라이언트에서는 자동 리다이렉트가 되어 GET으로 Location으로 요청을 하게 되어 응답을 받고, 그 뒤로는 실수(혹은 의도적)로 새로고침을 하더라도 중복 주문이 되지 않는다.
-
요약
- 302 Found → GET으로 변할 수 있다.
- 307 Temporary Redirect → 메서드가 변하면 안 된다.
- 303 See Other → 메서드가 GET으로 변경
-
역사
- 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것이었다. 하지만 웹 브라우저들이 대부분 GET으로 바꿔버리면서 동작이 모호해졌다. 그렇기에 모호한 302를 대신하는 307, 303이 등장했다.
-
현재
307, 303을 권장
하지만 현실적으로 이미 많은애플리케이션 라이브러리들이 302를 기본값
으로 사용.- 자동 리다이렉션시에 GET으로 변해도 되면 302를 사용해도 별문제가 되지 않는다.
-
300 Multiple Choices : 사용하지 않는다. -
304 Not Modified
- 캐시를 목적으로 사용한다.
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다.
- 304 응답은 응답에 메시지 바디를 포함하면 안 된다. (로컬 캐시를 사용해야 하기에)
- 조건부 GET, HEAD 요청 시 사용
- 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음.
- 오류의 원인이 클라이언트에 있을 경우.
- 클라이언트가 이미 잘못된 요청과 데이터를 보내고 있기에 재시도를 하더라도 계속 실패.
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없는 에러
- 요청 구문, 메시지 등등에서 문제가 있을 때 발생
- 클라이언트는 요청 내용을 재검토하고 수정해서 보내야 한다.
- 💡 서버단에서 스펙에 안 맞는 요청이 오면 철저하게 검증해서 400 상태 코드를 반환해서 해당 케이스에 500 에러로 서버 문제로 넘어가지 않아야 한다.
클라이언트가 해당 리소스에 대한 인증이 필요한 경우 발생
-
인증(Authentication) 되지 않음
-
401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
-
참고
인증(Authentication)
: 본인이 누구인지 확인(로그인)
인가(Authorization)
: 권한 부여(Admin 권한처럼 특정 리소스에 접근할 수 있는 권한
, 인증이 있어야 인가가 있다.)- 오류 메시지가 Unauthorized이지만 인증되지 않음
서버가 요청을 이해는 했지만 승인을 거부하는 경우
- 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
- 일반 사용자가 운영자 등급의 리소스에 접근하고자 할 때 발생
요청 리소스를 찾을 수 없을 때 발생
- 요청 리소스가 서버에 없음
- 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때
서버에서 오류가 발생했을 때 반환되는 상태 코드
- 서버 문제로 오류가 발생
- 클라이언트가 실패했을지라도 나중에 똑같은 요청을 했을 때 성공할 가능성이 있다.
서버 문제로 오류가 발생했고, 애매한 경우 500 오류
- 서버 내부 문제로 오류가 발생
- 애매하면 모두 500 오류를 낸다.
- 💡
서버가 아닌 비즈니스 조건에 문제가 되는 경우 500 에러를 사용해서는 안 된다.
서비스 이용 불가
- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음.
- Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수 있다.
- 대부분 예측 불가능한 에러기에 503 에러를 보는 경우는 흔치 않다.