HTTP 상태코드

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 수강하며 정리한 글입니다.

상태 코드

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

상태코드를 많이 사용하는 것은 상황에 따라 적합하지 않을 수 있다.
상태코드는 클라이언트와 서버와의 약속이고, 보통 많이 사용하는 상태코드를 사용하며,
개발하는 팀에 따라서 상태 코드를 제한하는 등 이 약속을 적합하게 사용하는 것도 중요하다.

종류

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

만약 모르는 상태 코드가 반환된다면?

• 정해지지 않은 상태코드를 서버가 반환한다면?
• 클라이언트는 상위 상태코드로 해석해서 처리한다.
• 위 특징으로 새로운 상태 코드가 추가되거나 하는 경우에 클라이언트를 수정하지 않아도 된다.

예시)

• 279??? → 2xx(Successful)
• 471??? → 4xx(Client Error)
• 598??? → 5xx(Server Error)

주요 상태코드들

2xx (Successful)

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

• 200OK : 요청 성공
• 201Created : 요청을 성공해서 새로운 리소스가 생성됨
• 202Accepted : 요청이 접수되었으나 처리가 완료되지 않음.
• 204No Content

200 OK

---

Request

GET /members HTTP/1.1
Content-Type: application/json

Response

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ~

[
 {
    "username": "user1",
    "age": 30
 },
 {
    "username": "user2",
    "age": 20
 }
]

---

201 Created

자원 생성용도, 생성된 리소스는 응답의 Location헤더 필드로 식별

---

Request

POST /members HTTP/1.1
Content-Type: application/json

{
    "username": "user3",
    "age": 40
}

Response

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: ~
Location: /members/2

{
    "username": "user3",
    "age": 40
}

---

202 Accepted

요청이 접수되었으나 처리가 완료되지 않음

• 요청은 지금 하고 1시간 뒤 실행하도록 작업을 예약할 때
• ex) 배치

---

204 No Content

서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

• ex) 웹 문서 편집기의 save 버튼
• save 버튼의 결과로는 아무 내용이 없어도 됨.
• save 버튼을 눌러도 같은 화면을 유지해야 함.
• 결과 내용이 없어도 204 (2xx)메시지만으로 성공을 인식할 수 있음.

3xx (Redirection)

요청을 완료하기 위해 유저 에이전트(클라이언트 프로그램 = 웹 브라우저) 의 추가 조치 필요

• 300 Mulitiple Choices : 잘 안 씀
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

리다이렉션 이해

• 3xx 응답 결과에 Locaiton 헤더가 존재한다면, Location 위치로 자동 이동(리다이렉트)
• B로 접속하지 않고 A라는 URL로 요청했는데 B라는 URL로 변경되어 요청하게 됨
• ex) /members → /users

종류

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

영구 리다이렉션

301, 308

• 리소스의 URI가 영구적으로 이동된 경우에 사용 ex) /members → /users
• 현재 사용하던 경로가 완전히 변경됨 을 알려주기 위함.
• 원래의 URL 사용 X 검색 엔진 등에서도 변경 인지
• 301 Moved Permanently : 영구적으로 이동 됨
  • 리다이렉트 시 요청 메소드가 GET으로 변함, 본문이 제거될 수 있음
• 308 Permanent Redirect : 영구 리다이렉션
  • 리다이렉트 시 요청 메소드, 본문 유지(처음 요청이 POST면 리다이렉트도 POST 유지)

301 308 리다이렉트 기능은 같으나 요청 메소드와 본문이 유지됨에 있어서 차이가 있음.

URL이 바뀌면 클라이언트에서 서버로 보낼 데이터 스펙이 변경될 수 있음
왠만하면 301 GET으로 변환하는 게 좋음

일시적인 리다이렉션

302, 307, 303

• 리소스의 URI가 일시적으로 변경
• 일시적 변경이기 때문에 검색 엔진 등에서 URL을 변경하면 안됨.
• 302 Found
  • 리다이렉트시 요청 메소드가 GET으로 변하고 본문이 제거될 수 있음
• 307 Temporary Redirect
  • 302와 기능 동일
  • 요청 메소드, 본문 유지
• 303 See Other
  • 302와 기능 동일
  • 리다이렉트시 요청 메소드가 GET으로 변경됨

실무에서 많이 씀

각각 리다이렉션하는 기능이 같으나 조금씩 차이가 있음
302는 메소드를 GET으로 변환, 본문이 제거될 수도 있고 아닐 수도(MAY) 대부분 변경되긴 함.
303은 요청 메소드가 GET으로 변경됨 (ex POST 요청 → 리다이렉트 GET 요청)
307은 요청 메소드, 본문 유지
303은 명확하게 GET으로 변경되는 것이지만, 302를 사용해도 크게 문제가 없다고 함

PRG( Post, Redirect, Get ) 패턴

아래 상황이 생길 수 있다.

• POST로 주문 후에 웹 브라우저를 새로고침하면?
• 새로고침으로 다시 요청 → 중복 주문 요청이 발생 한다
• 물론 서버에서 이를 막아야하긴 하지만, 클라이언트 측에서도 방지해주기 위해서
• 요청 메소드를 GET으로 변경해서 이를 방지해주는 것이 PRG 패턴이다.
• 이렇게 하면 요청 메소드가 GET으로 변경되었기 때문에 새로고침을 해도 GET으로 결과 화면만 조회하게 된다.

따라서 중복 요청을 막기 위해 POST → Redirect → 요청 메소드를 GET으로 변경하는 PRG 패턴을 가지는 것이 안정적이다.

또한 PRG 패턴을 사용하면 서버 측에서 중복 주문 에러에 대한 로그도 줄어들게 된다.

그래서 302, 307, 303 중 뭘 사용해야 하나?

• 정리
  • 302 Found → GET으로 변할 수 있음
  • 307 Temporary Redirect → 메소드가 변경되지 않음
  • 303 See Other → GET으로 변함
• 역사
  • 처음 302 스펙의 의도는 HTTP 메소드 유지를 위한 것이었다고 함.
  • 그런데 웹 브라우저들 대부분이 GET으로 바꿔버렸고(일부는 다르게 동작)
  • 스펙에 대한 모호함이 생김
  • 그래서 모호한 302를 대신하는 명확한 307, 303이 등장하게 됨 (+ 301 대응으로 308 등장)
• 현실
  • 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
  • 자동 리다이렉션시에 GET으로 변해도 되면 302를 사용해도 큰 문제가 없음

기타 리다이렉션

300, 304

• 300 Multiple Choices : 안 씀
• 304 NOT MODIFIED : 진짜 많이 쓴다고 함
  • 캐시를 목적으로 사용
  • 서버가 클라이언트에게 리소스가 수정되지 않았음을 알려주기 위함 (캐시로 리다이렉트 함)
  • 클라이언트가 서버에게 "내가 이 이미지를 가지고 있는데 이걸 써도 돼?" 라고 물어보고
  • 서버에서는 "리소스가 수정되지 않았으니 사용해도 돼" 라는 응답을 하는 것
  • 로컬 캐시를 사용해야 하므로 response에 body를 포함하면 안됨.
  • 조건부 GET, HEAD 요청 시 사용

4xx (Client Error)

• 오류의 원인이 클라이언트에 있음
• 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
• 4xx 오류는 클라이언트 요청에 대해서 오류가 있기때문에 같은 데이터를 보내도 오류가 발생해야함.
• 중요 : 5xx 오류가 터지다가 서버가 복구되면 같은 요청을 보냈을 때 오류가 발생하지 않게되는데, 이런 경우에는 4xx를 쓰지 않는 것이 적합함
• 즉, 이미 잘못된 요청은 같은 재시도도 실패해야 함.

4xx error 에서는 실패한 요청을 똑같이 재요청 했을 때 같은 응답(실패)이어야 함을 주의

• 400 Bad Request
  • 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음.
  • 요청 구문, 메시지 등의 오류(요청 파라미터, API 스펙 등)
  • 클라이언트는 요청 내용을 다시 검토하고 보내야함.
• 401 Unauthorized
  • 인증(Authentication) 되지 않음
  • 401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
  • 인증 : 본인이 누구인지 확인 (로그인)
  • 인가 : 권한 부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
  • 오류 메시지가 Unauthorized(인가 안됨)이지만 인증되지 않음을 의미 (이름이 아쉬운 편)
• 403 Forbidden
  • 서버가 요청을 이해했지만, 권한이 없어 승인을 거부
  • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
  • ex) admin이 아닌 일반 user가 admin 등급의 리소스에 접근하는 경우
• 404 Not Found
  • 서버가 리소스를 찾을 수 없음
  • 서버 입장에서는 해당 리소스가 없는데 클라이언트가 요청한 상황
  • 따라서 클라이언트가 잘못된 요청을 함을 의미
  • 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 사용

5xx (Server Error)

• 서버 문제로 오류 발생
• NullPointExecption, DB 관련 등등..
• 서버 문제이기 때문에 서버가 복귀되면 재 요청 시 성공
• 500 Internal Server Error
  • 서버 내부 문제로 오류 발생, 애매하면 500 오류 발생 시킴
• 503 Service Unavailable
  • 서비스 이용 불가
  • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음을 의미
  • Retry-After 헤더 필드로 얼마뒤에 복구되는 지 보낼 수 있음
  • 그러나 대부분 예측 불가능하기에 바로 500 error가 나오는 경우가 많음.

5xx error는 진짜 서버에 문제가 있을 때만 발생시키자

ex ) 20세 이상에게 적용하는 서비스인데 15세가 접속했다? 이 경우에는 400으로 해결하는 방향으로 고민

마무리

• 1xx Informational
  • 요청이 수신되어 처리 중
  • 거의 안 씀
• 2xx Success
  • 요청 성공
• 3xx Redirection
  • 요청을 완료하기 위해 추가 조치(리다이렉션) 가 필요함
• 4xx Client Error
  • 클라이언트의 요청 오류(요청 파라미터, API 스펙 등)
  • 실패하는 요청은 같은 요청을 재시도 해도 실패해야함
• 5xx Server Error
  • 서버 내부 오류
  • 서버 내부 오류가 고쳐진다면 재 요청 시 성공