HTTP 상태 코드

상태 코드란?

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

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

 

---

 

2xx (Successful)

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

• 200 OK
   
• 201 Created
  "요청이 성공해서 새로운 리소스가 생성됐다"
  생성된 리소스는 응답의 Location 헤더 필드로 식별
  

  

  201과 함께 Location 헤더를 보낸다.

   
• 202 Accepted
  "요청이 접수되었으나, 처리가 완료되지 않았다"
  예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우
• 204 No Content
  "서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없다"
  예) 웹 문서 편집기에서 중간 저장용 save 버튼 - save 버튼의 결과로 아무 내용이 없어도 된다

---

3xx (Redirection)

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

※ 유저 에이전트: 클라이언트 프로그램. (주로 웹 브라우저)

 

• 300 Multiple Choices (안 쓰인다)
• 301 Moved Permanently (변경 가능성)
  308 Permanent Redirect (유지)
• 302 Found (변경 가능성)
  303 See Other(유지)
  307 Temporary Redirect(변경)
• 304 Not Modified

리다이렉션이란?

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다 (redirect)

 

예) 이벤트 페이지가 /event였는데 /new-event로 바뀐 경우.

/event로 들어오면 /new-event의 위치를 알려줘 재요청하도록 한다

브라우저가 알아서 새 URL로 요청한다

리다이렉션의 종류

1. 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
   예) /event -> /new-event
    
2. 일시 리다이렉션 - 일시적인 변경
   예) 주문 완료 후 주문 내역 화면으로 이동
   PRG(Post/Redirect/Get) 패턴
   
   
3. 특수 리다이렉션
   캐시로 리다이렉트

 

영구 리다이렉션

301, 308

"리소스의 URI가 영구적으로 이동했다" (원래의 URL을 사용하지 않는 상황)

+ 검색 엔진이 이러한 변경을 숙지하게 된다.

 

• 301 Moved Permanently
  리다이렉트시 요청 메서드가 GET으로 변할 수도 있다 (바디가 제거될 수 있다)
  
• 308 Permanent Redirect
  리다이렉트시 요청 메서드와 본문을 유지한다 (처음 POST를 보내면 리다이렉트도 POST 유지)

[301] POST에서 GET으로 바뀌면서 메시지가 제거됐다.

 

[308] POST가 유지되어 메시지가 유지된다.

그런데 실무에선 308을 거의 쓰지 않는다.
페이지가 변경되면 대부분 내부적으로 전달해야 할 데이터 자체도 바뀌기 때문이다.

 

일시적인 리다이렉션

302, 307, 303

"리소스의 URI가 일시적으로 변경됐다"

• 302 Found
  새 경로를 찾았다, 거기로 가라
  리다이렉트 시 요청 메서드가 GET으로 변경될 수 있음(MAY)
• 307 Temporary Redirect
  리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다안 된다. MUST NOT)
• 303 See Other
  리다이렉트시 요청 메서드가 GET으로 변경(MUST)

# PRG: Post/Redirect/Get

[문제 상황]

주문 요청(POST) 후에 브라우저를 새로고침하면,

마지막 요청이 다시 요청되어 중복 주문이 될 수 있다.

POST가 재요청 된다

[해결]

주문 요청 처리 후, GET 메서드로 리다이렉트 시킨다.(주문 결과 화면)

이로써 POST 요청이 다시 요청되지 않는다.

GET이 재요청 된다

 

Q. 그래서 302, 307, 303 중 뭘 써야 하는가?

302는 명확하지 않으므로 명확한 307, 303을 권장하지만, 이미 많은 애플리케이션이 302를 기본값으로 사용하고 있다.

따라서 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제는 없다.

 

캐시 리다이렉션 - 304 Not Modified

"리소스가 수정되지 않았다"

서버: 브라우저야, 데이터가 변경되지 않았으니 캐시에 있는 걸 써~

유저 에이전시: 로컬 PC에 저장된 캐시를 사용한다(캐시로 리다이렉트한다)

• 304 응답은 응답에 메시지 바디를 포함하면 안된다.
• 조건부 GET, HEAD 요청시 사용한다.

 

[redirect vs forward]
forward는 서버 내부에서 다시 호출이 발생하는 것이다.
리다이렉트는 실제 클라이언트(웹 브라우저)에 응답이 나갔다가, 클라이언트가 redirect 경로로 다시 요청한다.
따라서 클라이언트가 인지할 수 있고, URL 경로도 실제로 변경된다.
반면에 포워드는 서버 내부에서 일어나는 호출이기 때문에 클라이언트가 전혀 인지하지 못한다.

 

---

4xx (Client Error)

"오류의 원인이 클라이언트에 있다"

클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없다

 

요청 자체가 잘못됐기 때문에 재시도해도 실패한다.

따라서 클라이언트는 요청 내용을 다시 검토하고, 보내야 한다

예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때

401 Unauthorized

"인증(Authentication) 되지 않았다"

클라이언트가 해당 리소스에 대한 인증이 필요하다(로그인)

- 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명

 

※ 참고
- 인증(Authentication): 본인이 누구인지 확인 (로그인)
- 인가(Authorization): 권한 부여(ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있다)

403 Forbidden

"승인을 거부한다"

서버가 요청을 이해했지만 승인을 거부한다. 주로 권한이 불충분한 경우.

예) 어드민 등급이 아닌 사용자가 어드민 등급의 리소스에 접근하는 경우

404 Not Found

"요청 리소스를 찾을 수 없다"

※ 리소스가 없는 게 아니라, 클라이언트가 권한이 없는 접근할 때 해당 리소스를 숨기고 싶을 경우 쓰기도 한다

 

---

5xx (Server Error)

"서버 문제로 오류가 발생"

서버에 문제가 있기 때문에, 같은 요청을 재시도 하면 성공할 수도 있다(복구가 되거나 등등)

500 Internal Server Error

"서버 문제로 오류 발생"

• 애매하면 500 오류

503 Service Unavailable

"서비스 이용 불가"

• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없다
• Retry-After 헤더 필드로 얼마뒤에 복구되는지 알려줄 수도 있다

 

 

---

 

참고 자료 & 이미지 출처
모든 개발자를 위한 HTTP 웹 기본 지식 (김영한 님)
컴퓨터 네트워킹 : 하향식 접근 7판 (JAMES F.KUROSE)