✅ HTTP 상태코드란?
클라이언트가 보낸 요청의 처리 상태를 응답에서 숫자로 표현하여 알려주는 기능이다. 보통
100~500사이의 숫자로 표현된다.
☑️ 1xx(informational) : 요청이 수신되어 처리중
☑️ 2xx(Successful) : 요청 정상 처리
☑️ 3xx(Redirection) : 요청을 완료하려면 추가 행동이 필요
☑️ 4xx(Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 처리할 수 없음.
☑️ 5xx(Server Error) : 서버 오류, 서버가 정상요청을 처리하지 못함.
참고❗ 만약, 클라이언트가 인식할 수 없는 상태코드를 서버로부터 받으면, 상위 상태 코드로 해석하여 처리한다. 따라서 미래에 새로운 상태코드가 추가되어도 클라이언트를 변경하지 않아도 된다.
- 예1)
299 ???➡️2xx(Successful) - 예2)
451 ???➡️4xx(Client Error) - 예3)
599 ???➡️5xx(Server Error)
✅ 1xx(informational)
요청이 수신되어 처리중인 상태
☑️ 거의 사용되지 않는다.
✅ 2xx(Successful)
클라이언트의 요청을 성공적으로 처리한 상태
☑️ 200 OK
- 가장 많이 보내는 응답 메시지로
GET과 같은 조회 요청에 대하여 성공적으로 요청을 받아서 결과를 정상적으로 처리해 응답할 경우 해당 상태코드를 반환한다.
☑️ 201 Created
- 요청이 성공해서 새로운 리소스가 생성된 경우 반환하는 상태코드이다. 이때 응답메시지에는 생성된 리소스를
Location헤더 필드로 인식한다.
☑️ 202 Accepted
- 요청이 접수되었으나 처리가 완료되지 않았음.
예) 요청 접수 1시간 뒤에 배치 프로세스가 요청을 처리할 경우등에 사용
☑️ 204 No Content
- 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없는경우의 상태코드이다.
예) 웹문서 편집기에서 저장버튼을 눌렀을 경우 그 요청결과로 딱히 어떤 응답 내용이 필요하지는 않다. 결과 내용 없이도 204코드만으로 요청 성공을 인식하기만 하면된다.
✅ 3xx(Redirection)
요청을 완료하기위해 유저 에이전트의 추가 조치가 필요한 경우의 상태코드이다. 유저 에이전트는 주로 웹 브라우저를 말한다.
☑️ 300 Multiple Choices : 사용하지 않는다.
☑️ 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음.
☑️ 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음.
☑️ 303 See other : 리다이렉트시 요청 메서드가 GET으로 변경
☑️ 304 Not Modified : 캐시를 목적으로 사용하며 응답에 메시지 바디를 포함하지 않는다.
☑️ 307 Temporary Redirect : 리다이렉트 요청 메서드와 본문을 유지한다.
☑️ 308 Permanent Redirect : 리다이렉트시 요청메서드와 본문을 유지한다.
✅ 리다이렉션(Redirection)의 이해
웹 브라우저는
3xx응답의 결과에Location 헤더가 있으면,Location 위치로 자동 이동(리다이렉트)
- 만약, 기존 이벤트 페이지가 새로운 이벤트 페이지로 변경되었을때 기존의 이벤트 페이지가 이미 공유되었거나 즐겨찾기에 등록되어 있을수도 있으므로 새로운 경로로 자동으로 이동되도록 리다이렉트 한다.
[자동 리다이렉션의 흐름]
✅ 리다이렉션(Redirection)의 종류
☑️ 영구 리다이렉트 : 특정 리소스의 URI가 영구적으로 이동
예1) /members ➡️ /users
예2) /event ➡️ /new-event
☑️ 일시 리다이렉션 : 일시적인 변경
주문완료 후 주문 내역 화면으로 이동
PRG : POST/Redirect/GET
☑️ 특수 리다이렉션
결과 대신 캐시를 사용
✅ 영구 리다이렉션 - [301, 308]
특정 리소스의
URI가 영구적으로 이동된다. 이전URI는 사용하지 않는다. 검색엔진에서도URI변경을 인지하여 새로운URI를 적용한다.
[301 Moved Permanently]
- 리다이렉트시 요청 메서드가
GET으로 변하고 본문이 제거될 수 있다. 그럼 다시POST로 기존의 메시지를 보내 요청한다.
[308 Permanent Redirect]
- 리다이렉트시 요청메서드와 본문이 유지된다. 처음 요청 메시지 전송시
POST를 사용했다면 리다이렉트시에도POST를 유지해야 한다.
✅ 일시적인 리다이렉션 - [302, 303, 307]
리소스의
URI가 일시적으로 변경된다. 따라서 검색 엔진등에서URI를 변경하면 안된다.
☑️ 302 Found
- GET으로 변할 수 있다.
☑️ 307 Temporary Redirect
- 메서드가 변하면 안된다.
☑️ 303 See Other
- 메서드가 GET으로 변경
☑️ 302, 303, 307 세가지의 상태코드 기능은 거의 동일하다.
✅ PRG(POST / Redirect / GET) - 일시적인 리다이렉션 예시
예를 들어 POST를 사용하여 주문 요청 처리 후 웹 브라우저를 새로고침하면 어떻게 될까? ➡️ 새로 고침은 재요청이므로 주문이 중복 처리될 수 있다.
[PRG 사용전]
POST로 주문을 요청하면 주문 데이터에 주문을 저장한 뒤 처리완료 응답을 한다.- 만약 결과 화면에서 새로고침을 누르면 마지막 요청을 다시 보내는 행위이기 때문에 중복 주문이 발생한다.
[PRG 사용후]
- 주문후에 주문결과 화면을
GET으로 리다이렉트하게하면 새로고침을 해도GET조회만 발생한다. 중복주문 대신 결과 화면만 요청하는 것이다. - 클라이언트가 최초에
POST로 주문을 요청하면 서버는 응답시200이 아닌302나303코드를 응답한다. 그럼 클라이언트가 상태코드를 확인하고GET으로 자동 리다이렉트 하도록 한다. 즉, 새로고침을 해도GET결과 화면만 다시 요청하는 것이다.
참고❗ 처음
302상태 코드의 스펙은HTTP 메서드를 유지하는 것이었다. 하지만 대부분의 웹 브라우저들이GET으로 바꾸어 버렸고 대안으로303과307이 등장했다.
303과307을 권장하지만 많은 애플리케이션과 라이브러리들이 302를 이미 사용하고 있으므로 자동 리다이렉션시에GET으로 변해도 상관없다면302상태코드를 사용해도 된다.
✅ 기타 리다이렉션 - [300, 304]
☑️ 300 Multiple Choices
- 사용하지 않는다.
☑️ 304 Not Modified
- 캐시를 목적으로 사용
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 사용한다.(캐시로 리다이렉트 한다.)
- 응답에 메시지 바디를 포함하면 안된다.(로컬 캐시를 사용하기 때문)
- 조건부
GET,HEAD요청시 사용
✅ 4xx(Client Error)
클라이언트가 잘못된 요청을해서 서버가 요청을 수행할 수 없을때 사용하는 상태코드이다. 오류의 원인이 클라이언트에 있기 때문에 같은 요청을 재시도해도 성공할 수 없다.
☑️ 400 Bad Request
- 클라이언트가 잘못된 요청을해서 서버가 처리할 수 없을 때 발생하는 상태코드
- 요청 파라미터가 잘못되었거나 API 스펙이 맞지 않을때 발생한다.
- 클라이언트가 요청내용을 다시 검토하고 보내야 한다.
- 백엔드 개발자는 철저하게 검증(validation)해서 스펙이 안맞으면 400 상태코드를 반환해
500오류로 서버문제로 넘어가지 않게 해야한다.
☑️ 401 Unauthorized
- 클라이언트가 해당 리소스에 대한 인증이 필요한 경우 발생하는 상태코드
- 인증(authorization)되지 않음.
- 401 오류 발생시 응답에
WWW-Authenticate헤더와 함께 인증 방법을 설명해야 한다.- 인증(Authentication) : 본인여부 확인(로그인)
- 인가(Authorization) : 리소스 접근 권한확인(특정 리소스 접근권한)
- 오류 메시지가
Unauthorized이지만 인증이 되지 않았을 때 발생하는 상태이다.
☑️ 403 Forbidden
- 서버가 요청을 이해했지만 승인을 거부함.
- 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
- 일반 사용자가 관리자 권한의 리소스에 접근하고자 할 때 발생.
☑️ 404 Not Found
- 요청 리소스를 찾을 수 없는 상태
- 클라이언트가 권한이 부족한 리소스에 접근하려 하는경우 해당 리소스를 숨기고 싶을때 사용
✅ 5xx(Server Error)
서버에 문제가 생겨 발생하는 오류이다. 따라서 서버 복구시 같은 요청을 재시도하면 성공할수도 있다.
☑️ 500 Internal Server Error
- 서버 내부 문제로 인한 오류
- 애매한 문제는 대부분 500 오류로 처리한다.
☑️ 503 Service Unavailable
- 서비스 이용 불가
- 서버가 일시적인 과부하에 걸리거나 예정된 작업으로 잠시 요청을 처리할 수 없는 상태
Retry-After헤더필드로 얼마뒤에 복구되는지 보낼 수 있다.
참고❗ 서버는 비즈니스 로직상 발생하는 문제를 500 오류로 처리해서는 절대 안된다. 진짜 서버에 문제가 터졌을 경우에만 발생시켜야한다.
예) 잔고가 부족하거나 필요한 연령제한을 못넘겨서 발생하는 예외는 비즈니스 로직상 정상 예외 케이스이므로 2xx 또는 4xx 상태코드로 해결하고 DB에러 등 서버자체에서 발생하는 문제일 경우에만 500에러로 처리하도록 한다.
[Reference]
gparkkii.log
Catsbi's Dlog
김영한 - HTTP 웹 기본지식 강의
Mozilla
kyun2da.dev
개발왕 도던
