본 게시글은 인프런의 모든 개발자를 위한 HTTP 웹 기본 지식 (김영한) 강의를 듣고 정리한 내용입니다.
HTTP 상태코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
HTTP 상태코드의 종류
| 범주 | 설명 |
|---|---|
| 1xx (Informational) | 요청이 수신되어 처리 중 ( 잘 사용 안함 ) |
| 2xx (Successful) | 요청 정상 처리 |
| 3xx (Redirection) | 요청을 완료하려면 추가 행동 필요 |
| 4xx (Client Error) | 클라이언트 오류로 인해 요청 수행 불가 |
| 5xx (Server Error) | 서버 오류로 인해 요청 처리 불가 |
만약 모르는 상태 코드가 나타나면, 클라이언트는 상위 상태코드로 해석해서 처리
- 299 ??? -> 2xx (Successful)
- 451 ??? -> 4xx (Client Error)
- 599 ??? -> 5xx (Server Error)
2xx (Successful)
클라이언트의 요청을 성공적으로 처리 했을 때 사용하는 상태코드
200 OK
201 Created
응답에 Location 포함하여 리소스의 경로를 제공한다.
202 Accepted
요청이 접수되었지만, 처리는 완료되지 않음. 배치 처리 등에 사용된다.
ex ) 예약 요청이 승인 대기 상태일 때
204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
ex ) velog 의 임시저장 같은 기능이 있다.
3xx (Redirection)
요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치 필요할 때 사용하는 상태코드
리다이렉션이란 ?
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다.
예전에 /event 사용
-> 이후에 /new-event로 uri변경
-> /event를 통해 들어온 유저들에게 301 Moved Permanently 보냄
-> 경로를 자동으로 /new-event를 바꾸고 다시 요청영구 리다이렉션 (Permanent Redirection)
특정 리소스의 URI가 영구적으로 이동하는 것을 의미한다.
ex ) http://example.com/old-page → http://example.com/new-page
301 Moved Permanently
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
예를 들어, POST 메서드가 GET 메서드로 변경된다.
메시지 바디는 제거되며, 사용자는 처음부터 폼을 다시 작성해야 한다.
하지만 모든 경우에서 메시지 바디가 무조건 제거되는 것은 아니다.
308 Permanent Redirect
01과 기능은 같지만, 리다이렉트 시 요청 메서드와 본문을 유지함.
! 요청 메서드 유지 : POST -> POST
일시 리다이렉션 (Temporary Redirection)
리소스가 일시적으로 이동되었음을 나타낸다.
PRG (Post/Redirect/Get) 패턴을 적용하면 중복 요청을 방지할 수 있다. 이 패턴은 사용자가 POST 요청 후 리다이렉션을 GET 요청으로 처리하여 중복 제출을 방지하는 방식이다.
302 Found
- 일시적인 리다이렉션을 나타내며, 서버가 요청을 다른 URL로 임시로 리다이렉트한다.
- 리다이렉션 시, 요청 메서드는 GET으로 변경되며, 본문이 제거될 수 있다.
307 Temporary Redirect
- 302 Found와 기능은 비슷하지만, 중요한 차이점은 요청 메서드와 본문을 유지한다는 것이다. 즉, 리다이렉션 후에도 원래의 요청 메서드와 본문을 그대로 사용한다.
303 See Other
- 302 Found와 유사하지만, 리다이렉션 시 요청 메서드가 GET으로 변경된다.
- 이 응답은 POST와 같은 메서드에 의한 리소스 생성 후, 클라이언트가 리다이렉션을 통해 다른 리소스를 조회할 때 사용된다.
300, 304 기타 리다이렉션
300 Multiple Choices
- 요청에 대해 하나 이상의 응답이 가능함을 나타낸다.
- 이 응답은 실제로 거의 사용되지 않는다.
304 Not Modified
- 요청된 리소스를 재전송할 필요가 없음을 나타낸다.
- 캐시를 목적으로 사용되며, 캐시의 암묵적인 리다이렉트로 볼 수 있다.
- 서버는 클라이언트에게 리소스가 수정되지 않았음을 알려주며, 클라이언트는 로컬에 저장된 캐시를 재사용한다.
- 304 응답은 응답 본문을 포함할 수 없으며, 로컬 캐시를 사용해야 한다.
- 조건부 GET, HEAD 요청 시 사용된다.
PRG 패턴 (Post/Redirect/Get)
POST로 주문한 후 웹 브라우저를 새로고침하면, 다시 요청이 가서 중복 주문이 발생할 수 있다. 이러한 현상을 방지하기 위해 PRG (Post/Redirect/Get) 패턴을 활용할 수 있다.
PRG 패턴을 사용하면 POST로 주문한 후 새로 고침으로 인한 중복 주문을 방지할 수 있다. 주문 후, 결과 화면을 GET 메서드로 리다이렉트하기 때문에, 새로 고침을 해도 결과 화면을 GET 방식으로 조회하게 된다. 결과적으로 중복 주문이 발생하는 대신, 결과 화면만 GET으로 다시 요청된다.
4xx (Client Error)
오류의 원인이 클라이언트에게 있으며, 클라이언트가 잘못된 요청이나 데이터를 보냈기 때문에, 동일한 요청을 반복해도 실패한다.
400 Bad Request
- 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없을 때 발생한다.
- 요청 구문이나 메시지 등에 오류가 있을 때 발생한다.
- 클라이언트는 요청 내용을 다시 검토하고 수정한 후 전송해야 한다.
ex ) 요청 파라미터 오류, API 스펙 불일치
401 Unauthorized
- 클라이언트가 해당 리소스에 대한 인증을 거치지 않았을 때 발생한다.
- 인증되지 않음을 의미하며, 응답에는 인증 방법을 설명하는 WWW-Authenticate 헤더가 포함된다.
Authentication(인증): 본인이 누구인지 확인 (로그인 등)
Authorization(인가): 권한 부여 (admin 권한 등, 인증이 있어야 인가 가능)
403 Forbidden
- 서버가 요청을 이해했지만 승인을 거부했을 때 발생한다.
- 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우 발생한다.
ex ) 일반 사용자가 admin 등급의 리소스에 접근하려고 할 때
404 Not Found
- 요청된 리소스를 찾을 수 없을 때 발생한다.
- 또한, 클라이언트가 권한이 부족한 리소스에 접근하려고 할 때, 해당 리소스를 숨기기 위해 사용되기도 한다.
5xx (Server Error)
오류의 원인이 서버에게 있으며, 이에 재시도 시 성공할 수 있다.
500 Internal Server Error
- 서버 문제로 오류가 발생했을 때 발생하며, 애매한 오류일 경우 사용된다.
- 최대한 이 오류는 발생시키지 않도록 하며, 정말로 서버에 문제가 있을 때만 사용한다.
503 Service Unavailable
- 서버가 일시적인 과부하 또는 예정된 작업으로 인해 요청을 처리할 수 없을 때 발생한다.
- 서버는 잠시 후 복구될 수 있으며, 이때 Retry-After 헤더 필드를 통해 복구 시간을 알려줄 수 있다.
