HTTP 상태코드

이 포스트는 김영한님의 ‘모든 개발자를 위한 HTTP 웹 기본 지식’을 수강하고 작성하였습니다.

HTTP 상태코드

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

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

만약 모르는 상태 코드가 나타나면?

예) 서버에서 299번을 반환했는데, 클라이언트가 모르는 코드 번호다.

• 클라이언트는 상위 상태코드로 해석해서 처리
  • 예) 299번 상태코드는 200번대 상태코드로 처리
• 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨
• 예)
  • 299 ??? → 2×× (Successful)
  • 451 ??? → 4×× (Client Error)
  • 599 ??? → 5×× (Server Error)

1××

• 요청이 수신되어 처리 중
• 거의 사용하지 않음

2××

2××의 모든 코드를 다 사용하기엔 너무 많아서, 거의 200만 사용하는 경우도 많고, 200과 201만 사용하는 경우도 많다고 한다.

200 OK

1. 클라이언트가 /members/100의 리소스를 요청한다.
2. 서버에서 정상적으로 처리하면 200 OK와 함께 응답한다.

201 Created

1. 클라언트가 신규 리소스 등록을 POST로 요청한다.
2. 서버에서 리소스를 생성하고 리소스의 URI를 HTTP 헤더의 Location으로 지정한다.

202 Accepted

• 요청이 접수되었으나 처리가 완료되지 않았음
• 배치 처리 같은 곳에서 사용
  • 예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함
• 사실 잘 사용하지 않는다고 한다…

204 No Content

• 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
  • 예) 웹 문서 편집기에서의 save 버튼
    • save 버튼의 결과로 아무 내용이 없어도 된다.
    • save 버튼을 눌러도 같은 화면을 유지해야 한다.
    • 결과 내용이 없어도 204 메시지(2××)만으로 성공을 인식할 수 있다.

3××

• 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
• 300 Multiple Choices: 거의 안 씀
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

리다이렉션이란?

• 웹 브라우저는 3×× 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동

자동 리다이렉트 흐름

만약 이벤트 페이지(/event)가 있는데, 더이상 그 페이지를 쓰지 않고 새로운 이벤트 페이지(/new-event)를 쓴다고 하자.

1. 클라이언트가 /event를 GET으로 요청한다.
2. 서버는 301 응답 코드와 Location(/new-event)을 응답한다.
3. 클라이언트는 응답 받은 Location(/new-event)대로 경로를 수정한다.
4. 클라이언트는 바뀐 경로(/new-event)를 서버에 요청한다.
5. 서버는 클라이언트가 보낸 요청(/new-event)에 따른 페이지를 보여준다.

리다이렉션 종류

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

영구 리다이렉션 - 301, 308

• 리소스의 URI가 영구적으로 이동
• 원래의 URL을 사용하지 않음, 검색 엔진 등에서도 변경 인지

301 Moved Permanently

• 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

1. POST로 클라이언트가 서버에 요청(/event)을 보낸다. 이때 HTTP 메시지에는 메시지 바디가 존재한다.
2. 서버에서 클라이언트로 301 응답과 Location(/new-event)을 보낸다.
3. 클라이언트는 HTTP 요청 메서드를 GET으로 바꾸고, 메시지 바디 내용을 제거한 상태로 Location의 리소스(/new-event)를 요청한다.
4. 서버는 클라이언트에게 해당 리소스(/new-event)를 응답한다.

이렇게 하면 만약 클라이언트가 뭔가를 입력한 경우, 처음부터 새로 다시 입력해야 한다. name=hello, age=20…

308 Permanent Redirect

• 301과 기능은 같음
• 리다이렉트 시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST)

1. POST로 클라이언트가 서버에 요청(/event)을 보낸다. 이때 HTTP 메시지에는 메시지 바디가 존재한다.
2. 서버에서 클라이언트로 301 응답과 Location(/new-event)을 보낸다.
3. 클라이언트는 HTTP 요청 메서드인 POST와 메시지 바디 내용을 유지한 상태로 Location의 리소스(/new-event)를 요청한다.
4. 서버는 클라이언트에게 해당 리소스(/new-event)를 응답한다.

이러면 301의 처음부터 다시 입력이라는 문제를 해결할 수 있다. 그런데 실무에서는 애초에 페이지가 바뀌면 그에 필요한 데이터도 바뀌기 때문에, 308 방식 보다는 301 방식의 GET으로 리다이렉트 시켜버린다고 한다.

일시적 리다이렉션 - 302, 303, 307

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

실무에서 많이 쓴다고 한다. 스펙에서는 명확한 303과 307을 사용할 것을 권장하지만, 실제로는 많은 어플리케이션 라이브러리들이 302를 많이 쓴다고 한다. 자동 리다이렉션 시에 GET으로 변해도 되는 것에는 302를 써도 문제 없다.

302 Found

• 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

303 See Other

• 302와 기능은 같음
• 리다이렉트 시 요청 메서드가 GET으로 변경

307 Temporary Redirect

• 302와 기능은 같음
• 리다이렉트 시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안 된다. MUST NOT)

PRG: Post / Redirect / Get

• 일시적 리다이렉션 예시
  • POST로 주문 후에 새로 고침으로 인한 중복 주문 방지
  • POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
  • URL이 이미 POST에서 GET으로 리다이렉트 됐기 때문에, 새로고침해도 결과 화면을 GET으로 조회
  • 중복 주문 대신에 결과 화면만 GET으로 다시 요청

▼ PRG 사용 전

1. 클라이언트가 POST로 /order 리소스를 요청한다.
2. 서버는 데이터베이스에 메시지 바디대로 주문데이터를 저장한다.
3. 서버는 데이터베이스 저장이 끝나고 200 OK를 응답한다.
4. 클라이언트가 결과 화면(/order)에서 새로고침한다.
5. 클라이언트가 POST로 1.의 요청을 다시 보낸다.
6. 서버는 다시 2.의 동작을 한다.

원래는 서버에서 잘 막아야 하지만(잘못된 주문번호입니다 등), 클라이언트에서도 더 막을 수 있는 방법으로 PRG를 사용하는 것이다.

▼ PRG 사용

1. 클라이언트가 POST로 /order 리소스를 요청한다.
2. 서버는 데이터베이스에 메시지 바디대로 주문데이터를 저장한다.
3. 서버는 데이터베이스 저장이 끝나고 302 Found(또는 303 See Other)와 Location(/order-result/19)을 응답한다.
4. 클라이언트는 Location(/order-result/19)대로 자동 리다이렉트된다.
5. 클라이언트는 리소스(/order-result/19)를 서버에 요청한다.
6. 서버는 데이터베이스로부터 19번 주문 데이터를 조회한다.
7. 서버는 데이터를 HTML 화면을 만들어 클라이언트에 응답한다.
8. 클라이언트는 결과 화면(/order-result/19)에서 새로고침을 하더라도 결과 화면만 다시 요청한다(5. ~ 7. 반복).

특수 리다이렉션 - 300, 304

300 Multiple Choices

• 안 쓴다.

304 Not Modified

• 캐시를 목적으로 사용
• 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다(캐시로 리다이렉트 한다).
• 304 응답은 응답에 메시지 바디를 포함하면 안 된다(로컬 캐시를 사용해야 하므로).
• 조건부 GET, HEAD 요청 시 사용

4××

• 클라이언트 오류
• 클라이언트의 요청의 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
• 오류의 원인이 클라이언트에 있음
• 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함

400 Bad Request

• 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
• 요청 구문, 메시지 등등 오류
  • 예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때
• 클라이언트는 요청 내용을 다시 검토하고 보내야 함

401 Unauthorized

• 클라이언트가 해당 리소스에 대한 인증이 필요함
• 인증(Authentication) 되지 않음
• 401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
• 참고
  • 인증(Authentication): 본인이 누구인지 확인(로그인)
  • 인가(Authorization): 권한 부여(ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
  • 오류 메시지가 Unauthorized이면 인증되지 않음

403 Forbidden

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

404 Not Found

• 요청 리소스를 찾을 수 없음
• 클라이언트가 권한이 부족한 리소스에 접근하는데 해당 리소스를 숨기고 싶을 때

5××

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

로직 상 오류에도 5×× 에러를 남용하면 안 된다! 5×× 에러는 서버 오류에만 쓰자.

500 Internal Server Error

• 서버 문제로 오류 발생, 애매하면 500 오류

503 Service Unavailable

• 서비스 이용 불가
• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
• Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있음