HTTP 웹 지식 - HTTP 상태코드 소개

📌 김영한 님의 "모든 개발자를 위한 HTTP 웹 기본 지식" 강의 듣고 정리

 

📍상태코드 란?

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

 

HTTP/1.1 200 OK
Content-Type: application/json
Content-length: 34

{
   "username" : "young",
   "age" : 20
}

 

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

처음 보는 상태 코드가 있다?

클라이언트가 인식할 수 없는 상태코드를 서버가 반환하게 되면 클라이언트는 상위 상태코드로 해석해 처리하게 된다. 그래서 새로운 상태 코드가 추가 되더라도 클라이언트를 변경하지 않아도 된다. (ex. 299 ??? > 2xx (Successful))

 

 

📍1xx (Informational)

거의 사용하지 않으므로 생략

 

📍2xx - 성공

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

• 200 OK : 요청 성공
• 201 Created : 요청 성공해 새로운 리소스가 생성됨, 생성된 리소스는 Location 헤더 필드로 식별
• 202 Accepted : 요청 접수되었으나 처리는 미완료. 배치 처리 등에 사용. ex) 접수 뒤 1시간 뒤 배치 프로세스가 처리
• 204 No Content : 요청을 성공적으로 수행했으나 응답 페이로드 본문에 보낼 데이터 없음
  • 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식
  • ex) 웹 문서 편집기의 save 버튼 : 버튼 결과로 아무 내용 없어도 된다. 버튼을 눌러도 같은 화면을 유지해야 한다. 드의 경우

📍3xx - 리다이렉션

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

웹브라우저는 3xx 응답 결과에 Location 헤더가 있으면 해당 위치로 자동 이동(리다이렉트)한다. 

• 300 Multiple Choices : 사용안함
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

 

• 리다이렉션 흐름

 

• 리다이렉션의 종류
  • 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동 (ex. /members > /users)
    • 원래 URL 사용하지 않으며 검색 엔진 등에서도 변경을 인지한다.
    • 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET이 될 수도 있고, 본문이 제거될 수도 있다 (모호함)
    • 308 Permanent Redirect : 301과 기능이 같으나 처음의 요청 메서드와 본문이 유지 된다
  • 일시 리다이렉션 - 일시적인 잠깐 이동 (ex. 주문 완료 후 주문 내역화면으로 이동. PRG패턴)
    • 실무에서 많이 사용하는 방식
    • 리소스 URI가 일시적으로 변경하기 때문에 검색 엔진 등에서 URL을 변경하면 안된다. 
    • 302 Found : 리다이렉트시 요청 메서드가 GET으로 변할 수 있고, 본문이 제거될 수도 있다. 모호하다.
    • 303 See Other : 302와 기능은 같고 리다이렉트 요청 메서드가 GET으로 변경 (302가 기능 스펙에 대해 모호한 부분이 있다면 303은 확실하게 GET 메서드로 사용한다)
    • 307 Temporary Redirect : 302와 기능은 같으나 처음의 요청 메서드와 본문이 유지 된다 (요청 메서드 변경하면 안됨) 
    • 일시적 리다이렉션을 언제 쓸까?
      PRG패턴 (Post Redirect Get) : Post로 주문 후 새로고침할 경우 주문을 재요청하게 되여 중복 주문이 생길 수 가 있다. 이때 post로 주문하고 주문 결과 화면을 get으로 리다이렉트 하게되면 새로고침해도 결과 화면을 get요청하게 되니 중복을 피할 수가 있다. 

      

      PRG 사용전 새로고침하면 order가 재요청되어 5번 발생

       

      

      PRG 사용후 새로고침하면 했을 때는 주문 결과 화면을 GET요청하게 되어 중복 주문 방지

  • 특수 리다이렉션 - 결과 대신 캐시  
    • 304 Not Modified
      • 클라이언트에게 리소스가 수정되지 않았으니 로컬PC 캐시를 재사용하라며 캐시로 리다이렉트 시킴.
      • 304 응답은 응답에 메시지 바디를 포함하면 안된다(로컬 캐시를 사용해야 하므로).  
      • 조건부 GET, HEAD 요청시 사용

 

📍4xx (Client Error)

클라이언트 오류

• 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없을 때
• 오류의 원인이 클라이언트에 있음
• ❗클라이언트가 이미 잘못된 요청이나 데이터를 보내고 있어 똑같은 재시도는 몇번을 해도 실패할 수 밖에 없다. (복구 불가능)

 

• 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음. 요청 검토하여 다시 보내야 함
• 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요.
  • 인증(Authentication) 되지 않음
  • 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법 설명을 보낸다. 
  • 참고
    • 인증 (Authentication): 본인이 누구인지 확인
    • 인가 (Authorization): 권한부여 (인증이 있어야 인가가 있다)
• 403 Forbidden : 서버 요청 이해했지만 승인 거부, 주로 인증 자격 증명은 있으나 접근 권한이 없는 경우
• 404 Not Found : 요청 리소스가 서버에 없어 리소스 찾을 수 없음 또는 클라이언트가 권한이 부족한 리소스에 접근 시도 했을 때 리소스를 숨기고자 하면 사용

 

📍5xx (Server Error)

서버 오류

• 오류의 원인이 서버에 있음
• 서버에 문제가 있어 재시도하면 성공 할 수도 있다. (복구 등으로 상태가 변하여)

 

• 500 Internal Server Error : 서버 내부 문제로 오류 발생, 서버에서 발생한 에러가 애매한 경우 500으로
• 503 Service Unavailavle : 서비스 이용 불가. 일시적 과부화나 예정된 작업으로 요청을 처리할 수 없을 경우를 말한다. Retry-After 헤더 필드로 복구 시기를 알 수 있다.

 

들어온 데이터 값에 대한 예외를 500처리하면 안된다. 들어온 데이터의 문제고 로직상으로는 정상 작업된 것이기 때문. 따라서 클라이언트와 서버에서 발생한 오류를 명확하게 구분할 줄 알아야한다.