Skip to content

Latest commit

 

History

History
195 lines (138 loc) · 6.85 KB

6. HTTP 상태 코드.md

File metadata and controls

195 lines (138 loc) · 6.85 KB
Raw

6. HTTP 상태 코드

  • 상태 코드

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

1xx : 요청이 수신되어 처리중 (거의 사용x)

2xx : 요청 정상 처리

3xx : 추가 조치 필요

4xx : 클라이언트 오류

5xx : 서버 오류

→ 모르는 상태 코드가 있어도 대략적으로 어떤 상태(오류)인지 알 수 있음

2xx - 성공

1. 200 OK

  • 요청 성공
  • 보통 GET 메소드로 정상적인 조회를 했을 경우 Untitled 0

2. 201 Created

  • 요청 성공으로 새로운 리소스 생성
  • 보통 POST 메소드의 응답 메시지에 사용
  • 생성된 리소스의 URI는 응답 메시지의 location의 헤더로 식별 Untitled 1

3. 기타

  • 202 Accepted
    • 요청이 접수되었으나 처리가 완료되지 않음
    • ex) 1시간 뒤에 처리할 배치 프로세스
  • 204 No Content
    • 요청은 수행했으나 응답으로 보낼 데이터가 없음
    • ex) 웹 편집기 save 버튼

3xx - 리다이렉션

요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치가 필요

  • 응답 메시지의 Location 헤더가 있으면 Location 위치로 자동 이동 (리다이렉트)

  • 리다이렉션 과정

    1. 클라이언트가 요청 메세지 보냄
    2. 서버가 3xx 상태코드와 location 헤더에 정보를 담아서 응답 메시지 보냄
    3. 자동 리다이렉트로 location에 담긴 새로운 URL로 요청
    4. 서버가 응답 Untitled 2

  • 종류

    1. 영구 리다이렉션
      • 특정 리소스의 URI가 영구적으로 이동
    2. 일시 리다이렉션
      • 특정 리소스의 URI가 일시적으로 변경
      • PRG (Post→Redirect→Get)
    3. 특수 리다이렉션
      • 응답 결과 대신 캐시를 사용

1. 영구 리다이렉션 - 301, 308

  • 기존의 URL 사용x

  1. 301 Moved Permanently

    • 메소드가 GET으로 변경될 수 있음
    • 메세지바디가 제거될 수 있음 Untitled 3

  2. 308 Permanent Redirect

    • 메소드 & 메시지바디 그대로 유지
      • 실무에서는 URL이 바뀌는 경우 데이터를 새로 입력받아야 하는 경우가 많으므로 잘 사용하지 않음 Untitled 4

2. 일시 리다이렉션 - 302, 307, 303, 304

  • 리소스의 URI가 일시적으로 변경되기 때문에 검색 엔진 등에서 URL을 변경하면 안됨

  1. 302 Found → 가장 많이 사용

    • 메소드가 GET으로 변경될 수 있음

    • 본문이 제거될 수 있음

      → 301과 비슷

  2. 307 Temporary Redirect

    • 메소드와 본문 그대로 유지

      → 308과 비슷

  3. 303 See Other

    • 메소드가 GET으로 무조건 변함
    • 302와 기능은 같음
  • PRG (Post, Redirect, Get)
    • 중복 주문을 막을 수 있음
    • Post로 주문 후 Get 메서드로 Redirect
      • 새로고침 → 마지막 요청 다시 보냄
        • Post로 주문이 다시 들어가지 않고 Get으로 주문 결과 화면만 조회 Untitled 5
  1. 304 Not Modified
  • 클라이언트에게 리소스가 수정되지 않았음을 알려줌
  • 응답 결과를 사용하지 않고 이미 한번 받아서 저장되어 있는 캐시를 재사용함
    • 캐시로 리다이렉트
    • 응답 메시지에 바디를 포함하고 있지 않음 (로컬pc에 저장된 캐시를 사용하므로)
  • GET, HEAD 요청 시 사용

301, 302, 304 위주로 사용

4xx - 클라이언트 오류

클라이언트 요청의 잘못된 문법 등의 이유로 서버에서 요청을 처리할 수 없는 경우

  • 똑같은 요청을 계속 보내도 계속 실패함

1. 400 Bad Request

  • 클라이언트의 잘못된 요청
  • 다시 검토하고 보내야함

2. 401 Unauthorized (의미는 Unauthentication)

  • 해당 리소스에 대한 인증(authentication)이 필요함
    • 인증 (authentication)
      • 본인이 누구인지 확인 → 로그인
    • 인가 (authorization)
      • 특정 리소스에 대한 접근 권한이 있는지 확인
      • 인증을 받아야 인가를 받을 수 있음
        • 누군지 알아야 권한을 줄 수 있으니까
  • 의미상 인증이 필요한 것이므로 Unauthentication이 맞음

3. 403 Forbidden (의미는 Unauthorized)

  • 인증은 되었지만 해당 리소스에 대한 인가(authorization)이 필요함
  • 서버가 요청을 이해했지만 승인을 거부함

4. 404 Not Found

  1. 요청 리소스가 서버에 없는 경우
  2. 권한이 없는 클라이언트가 리소스에 접근할 때 해당 리소스를 숨기고 싶은 경우

5xx - 서버 오류

서버 문제로 인한 오류 (서버 다운, DB 오류 등)

  • 클라이언트가 같은 요청을 서버 문제가 해결된 뒤에 보내면 오류가 나지 않음
  • 5xx 에러는 진짜 서버에만 문제가 있을 때만 만들어야 함

1. 500 Internal Server Error

  • 서버 내부 문제
  • 애매하면 500 에러

2. 503 Service Unavailable

  • 서버 과부하 또는 예정된 작업으로 인한 요청 처리 불가

  • Retry-After 헤더에 얼마 뒤에 복구되는지 알려줄 수 있음

    → 대부분 장애는 복구 시간이 예측 안되기 때문에 웬만하면 500 에러를 사용함

정리

2xx - 200, 201

  1. 200 Ok
    • 요청(Get 조회) 성공
  2. 201 Created
    • 리소스 생성 성공

3xx - 301, 302, 304

  1. 301 Moved Permanetly(영구) & 302 Found(일시)
    • 메소드가 GET으로 변경
    • 메시지바디 제거
    • 302 → PRG 패턴에 사용
  2. 304 Not Modified
    • 리소스가 수정되지 않음을 알림
    • 메시지바디가 없고 캐시를 재사용(캐시로 리다이렉트)

4xx - 400, 404

  1. 400 Bad Request
    • 클라이언트의 잘못된 요청
  2. 404 Not Found
    1. 리소스가 서버에 없는 경우
    2. 권한이 없는 클라이언트가 리소스에 접근할 경우

5xx - 500

  1. 500 Internal Server Error
    • 서버 내부 에러