[HTTP] HTTP 상태코드

 

 

HTTP 상태코드

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
• 상태 코드 종류
  • 1xx (Informational) : 요청이 수신되어 처리중
  • 2xx (Successful) : 요청 정상 처리
  • 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
  • 4xx (Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
  • 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함

 

 

🔍 1xx (Informational)

• 요청이 수신되어 처리중
• 거의 사용하지 않는다.

 

 

🔍 2xx (Successful)

• 클라이언트의 요청을 성공적으로 처리
• 2xx 종류
  • 200 : OK
  • 201 : Created
  • 202 : Accepted
  • 204 : No Content
• 주로 200 또는 201 상태코드를 많이 사용한다.

 

💡 200 OK

• 요청 성공

 

💡 201 Created

• 요청 성공해서 새로운 리소스가 생성된다.
• 생성된 리소스는 응답의 Location 헤더 필드로 식별된다.
• 주로 Post로 등록 했을 떄 사용

 

 

 

💡 202 Accepted

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

 

💡 204 No contecnt

• 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없다.
• 예) 웹 문서 편집기에서 save 버튼
• save 버튼의 결과로 아무 내용이 없어도 된다.
• save 버튼을 눌러도 같은 화면을 유지해야 한다.
• 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.

 

 

🔍 3xx (Redirection)

• 요청을 완료하기 위해 유저 에이전트(클라이언트)의 추가 조치 필요
• 3xx 종류
  • 300 : Multiple Choices
  • 301 : Moved Permanently
  • 302 : Found
  • 303 : See Other
  • 304 : Not Modfied
  • 307 : Temporary Redirect
  • 308 : Permanent Redirect
• 301 ~ 308 까지의 상태코드가 중요하다.
• 클라이언트는 3xx 응답 결과에 Location 헤더가 있으면 Location 위치로 자동 이동한다. (리다이렉트)

 

💡 리다이렉트 흐름

 

💡 리다이렉션 이해

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

 

💡 영구 리다이렉션

• 301, 308 상태 코드
• 리소스의 URI가 영구적으로 이동한다.
• 원래의 URL를 사용하지 않는다.
• 검색 엔진 등에서 변경을 인지한다.
• 301 Moved Permanently
  • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문(메시지 바디)이 제거될 수 있다.
• 308 Permanent Redirect
  • 301과 기능이 같다.
  • 리다이렉트시 요청 메서드와 본문(메시지 바디) 유지
  • 처음 POST를 보내면 리다이렉트도 POST로 유지한다.
• 308 보단 301 상태코드를 더 많이 쓴다.

 

✔ 영구 리다이렉션 - 301

• 영구적으로 URI가 바뀌면서 GET 요청으로 바뀐다.

 

✔  영구 리다이렉션 - 308

• 영구적으로 URI가 바뀌고 POST 요청을 그대로 유지한다.

 

💡 일시적 리다이렉션

• 302, 307, 303 상태코드
• 리소스의 URI를 일시적으로 변경한다.
• 따라서 검색 엔진 등에서 URL을 변경하면 안된다.
• 307, 303 상태코드를 권장하지만, 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하고 있어서 302 상태코드가 많이 사용된다.
• 302 Found
  • 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문(메시지 바디)이 제거될 수 있다.
• 307 Temporary Redirect
  • 302와 기능이 같다.
  • 리다이렉트시 요청 메서드와 본문(메시지 바디)이 유지된다.
  • 요청 메서드가 변경되지 않는다.
• 303 See Other
  • 302와 기능이 같다.
  • 리다이렉트시 요청 메서드가 무조건 GET으로 변경된다.

 

✔ PRG : Post / Redirect / Get

• 일시적인 리다이렉션 예시
  • POST로 주문 후에 새로고침으로 인한 중복 주문을 방지한다.
  • POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트한다.
  • 새로고침해도 결과 화면을 GET으로 조회한다.
  • 중복 주문 대신에 결과 화면만 GET으로 다시 요청한다.

 

PRG 사용 전 문제점

• 주문 완료 후 새로 고침을 하면 중복 결제가 이뤄진다.

 

PRG를 사용하여 문제 해결

• PRG 사용 후 리다이렉트
  • URL에 이미 POST → GET 으로 리다이렉트 된다.
  • 새로 고침해도 GET으로 결과 화면만 조회한다.

 

💡 기타 리다이렉션

• 300 Multiple Choices 
  • 안 쓰인다.
• 304 Not Modified
  • 캐시를 목적으로 사용된다.
  • 클라이언트에게 리소스가 수정되지 않았음을 알려준다.
  • 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트한다.)
  • 304 응답은 로컬 캐시를 사용하므로 응답에 메시지 바디를 포함하면 안된다.
  • 조건부 GET, HEAD 요청시 사용한다.

 

 

🔍 4xx (Client Error)

• 클라이언트 오류
• 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없다.
• 오류의 원인이 클라이언트에 있다.
• 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 클라이언트가 똑같은 재시도를 해도 계속 실패한다.
• 4xx 종류
  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found

 

💡 400 Bad Request

• 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없다.
• 요청 구문, 메시지 등등 오류
• 클라이언트는 요청 내용 수정하고 다시 보내야 한다.
• 예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때

 

💡 401 Unauthorized

• 클라이언트가 해당 리소스에 대한 인증이 필요하다.
• 인증(Authentication)되지 않은 것이다.
• 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명 해줘야한다..
• 인증(Authentication) : 본인이 누구인지 확인 (로그인)
• 인가(Authorization) : 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있다.)

 

💡 403 Forbidden

• 서버가 요청을 이해했지만 승인을 거부한 것이다.
• 주로 인증 자격 증명은 했지만, 접근 권한이 불충한 경우
• 예) 어드민 등급이 아닌 사용자가 로그인은 했지만 어드민 등급의 리소스에 접근하는 경우

 

💡 404 Not Found

• 요청 리소스를 찾을 수 없다.
• 요청 리소스가 서버에 없다.
• 또는 클라이언트가 권한이 부족한 리소스에 접근하거나 해당 리소스를 숨기고 싶을 때 사용한다.

 

 

🔍 5xx (Server Error)

• 서버 문제로 오류
• 서버에 문제기 때문에 서버 복구 후 클라이언트가 요청 내용을 수정 없이 같은 요청을 재시도 하면 성공할 수 있다.

 

💡 500 Internal Server Error

• 서버 문제로 오류 발생
• 애매하면 500 오류로 사용할 것

 

💡 503 Service Unavailable

• 서비스 이용 불가
• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없을 때 사용한다.
• Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있다.

 

 

 

 

---

👀 참고 자료

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

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