HTTP 상태코드

상태코드

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

• 1xx: 요청 수신처리중
• 2xx: 요청 정상처리
• 3xx: 요청을 완료하려면 추가 행동 필요
• 4xx: 클라이언트 오류, 잘못된 문법등으로 서버 요청 수행 불가능
• 5xx: 서버 오류, 서버 정상 요청 처리 못한ㄷ나.

클라이언트 단에선

299가 와도 2xx 로 인지하고 처리하면 된다.

451가 와도 4xx 로 인지하고 처리하면 된다.

599가 와도 5xx 로 인지하고 처리하면 된다.

2xx - 성공

• 200: OK
• 201: Created
  • 생성된 리소스는 응답의 Location 헤더 필드로 식별
• 202: Accepted
  • 요청 접수되었으나 처리 완료되지 않았다.
• 204: No Content
  • 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
  • save 버튼의 결과로 아무 내용이 없어도 된다.
  • save 버튼을 눌러도 같은 화면을 유지해야 한다.
  • 결과 내용이 없어도 204메시지 만으로 성공을 인식할 수 있다.

3xx - 리다이렉션

요청을 완료하기 유저 에이전트의 추가 조치 필요 300~308

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
• 끝난 유저가 이벤트페이지에 접속시 서버에서 상태코드 301, Location 새로운 url 전달해서 클라이언트에서 바뀐 url로 리다이렉션됨

종류

• 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
  • 301, 308 스펙만 있을뿐 실무에선 301 GET으로 바꿔주어 처리
  • /members → /users
  • 리소스의 URI가 영구적으로 이동, 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지
  • 원래의 URL를 사용 ❌, 검색 엔진 등에서도 변경 인지한다.
  • 301 Moved Permanently
    • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
  • 308 Permanent Redirect
    • 301과 기능은 같음
    • 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST)
• 일시 리다이렉션 - 일시적인 변경 (실무에서 주로 일시 리다이렉션을 사용한다.)
  • 302, 307, 303
  • 주문 완료 후 주문 내역 화면으로 이동
  • PRG: Post/Redirect/Get
    • POST로 주문후에 웹 브라우저를 새로고침하게된다면?
    • 새로고침은 다시 요청(POST)
    • 중복 주문이 될 수 있다.
  • PRG 이후 리다이렉트
    • URL이 이미 POST → GET으로 리다이렉트 됨
    • 새로고침 해도 GET으로 결과화면만 조회
  • 302 Found
    • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
  • 307 Temporary Redirect
    • 302와 기능은 같음
    • 리다이렉시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
  • 303 See Other
    • 302와 기능은 같음
    • 리다이렉시 요청 메서드가 GET으로 변경
  • 처음 302 스펙 의도는 HTTP 메서드를 유지하는 것이었으나 웹 브라우저들이 대부분 GET으로 바꾸어버림(일부 다르게 동작)
  • 그래서 애매한 302 대신 명확한 307,303 등장
  • 하지만 현실에서 이미 많이 302를 기본값으로 사용한다
  • 자동 리다이렉션시에 GET으로 변해도 되면 사용해도 무방하다.
• 특수 리다이렉션
  • 304
  • 결과 대신 캐시를 사용
  • 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다.(캐시로 리다이렉트)
  • 304 응답은 응답에 메시지 바디를 포함하면 안된다(로컬 캐시를 사용해야함)
  • 조건부 GET, HEAD 요청시 사용한다.

4xx (Client Error)

클라이언트 오류

• 클라이언트의 요청에 잘못된 문법등으로 서버가 요청 수행 불가능
• 오류의 원인 클라이언트
• 이미 잘못된 요청, 데이터를 보내기 때문에 재시도해도 계속 실패

Bad Request

• 파리미터, API스펙 오류

401 Unauthorized

• 클라이언트가 해당 리소스에 대한 인증이 필요함
• 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법 설명

403 Forbidden

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

404 Not Found

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

5xx (Server Error)

• 서버 문제로 오류
• 서버 문제가 있기 때문에 재시도 하면 성공할 수도 있음(복구 되거나 등)

500에러는 진짜 서버 문제있을때만 내야한다.

예를들어 20세이상 서비스에 15세 접근시 비즈니스로직상 예외이기 때문에 500에러가 아닌 예외처리를 해주어야한다.