Chapter6. HTTP 상태코드
카테고리: Network
인프런에 있는 김영한님의 모든 개발자를 위한 HTTP웹 기본 지식 강의를 듣고 정리한 내용입니다.
중간에 등장하는 ppt 내용들은 모두 강의자료를 캡처한 것입니다.
✈️ HTTP 상태코드
TCP의 데이터 전달 보장 특징이 기억나는가? TCP/IP 패킷의 경우 요청 메시지를 보내면 잘 받았다는 응답 메시지를 받게된다. 사실 ‘잘 받았다’를 넘어서 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려준다. 이때 이용하는 것이 바로 HTTP 상태코드 이다.
- 1xx (Informational) : 요청이 수신되어 처리 중
- 2xx (Successful) : 요청 정상 처리
- 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
- 4xx (Client Error) : 클라이언트 오류
- 5xx (Server Error) : 서버 오류
✈️ 1xx Informational
거의 사용하지 않으므로 생략
✈️ 2xx Successful
- 200 OK
- 201 Created
- 202 Accepted
- 204 No Content
200 OK
요청 성공
201 Created
요청 성공해서 새로운 리소스가 생성. 이때 새로 생성된 리소스 URI를 메시지 헤더에 포함하여 응답한다.
202 Accepted
요청이 접수되었으나 처리가 완료되지 않았음
- 비동기 또는 배치 처리 같은 곳에서 사용
- 클라이언트가 요청의 완료 여부를 확일할 수 있는 방법을 제공해야 한다.
- Callback : 서버가 작업이 완료되면 클라이언트에게 알려줌
- Polling : 클라이언트가 주기적으로 해당 작업의 상태를 조회
204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
ex) 웹 문서 편집기의 save
- save 버튼의 결과로 아무 내용이 없음
- save 버튼을 눌러도 같은 화면을 유지해야 함
- 결과 내용이 없어도 204 상태코드만으로 성공을 인식할 수 있다.
✈️ 3xx Redirection
Redirection 작동 방식
클라이언트가 종료된 이벤트 페이지를 서버에게 요청했다고 가정해보자. 이때 서버가 다음과 같이 말하는 것이다.
"그거 이미 끝난 이벤트인데? 거기 말고 지금 진행하고 있는 새로운 이벤트 창으로 와"
서버가 3xx Redirect 상태코드와 함께 새로운 이벤트 페이지를 헤더에 포함하여 응답해주면 클라이언트는 자동으로 redirect 되고 새로운 이벤트 창을 다시 요청하게 된다.
3xx Redirect 종류
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 304 Not Modified
- 307 Temporary Redirect
- 308 Permanent Redirect
영구적인 Redirection - 301, 308
- 원래의 URI는 사용X. 리소스의 URI가 영구적으로 이동.(과거의 이벤트 페이지는 더 이상 쓰지 않음)
- 301 Moved Permanently
- redirect시 요청 method가 GET으로 변하고, 본문이 제거될 수 있음.(MAY)
- 308 Permanent Redirect
- 301과 기능은 같음
- redirect시 요청 method와 본문 유지
사실 완전히 새로운 URI로 이동하게 되면 클라이언트의 요청 메시지 본문은 의미가 없을 가능성이 크다. 실제로 실무에서 308은 거의 사용하지 않는다고 한다.
일시적인 Redirection - 302, 307, 303
만약 한 사용자가 마우스를 주문하고 POST 요청을 통해 결제를 처리했다고 가정해보자. 이때 사용자가 웹 브라우저를 새로고침하면 클라이언트는 새로운 요청을 보내게 되고 서버는 주문 완료 페이지를 응답해준다. 문제는 서버에 POST 요청이 한 번 더 가기 때문에 중복 결제가 이루어질 수 있다.
이런 현상을 막기 위해 PRG(Post/Redirect/GET) 즉, 일시적 redirection이 필요하다.
PRG 이후
- POST로 주문 후에 주문 결과 화면을 GET method로 redirect
- 새로고침해도 결과 화면을 GET으로 단순 조회 (중복 결제X)
302 vs 307 vs 303
- 302 Found : redirect시 요청 method가 GET으로 변하고, 본문이 제거될 수 있음. (MAY)
- 307 Temporary Redirect : redirect시 요청 method와 본문 유지 (MUST NOT)
- 303 See Other : redirect시 요청 method가 GET으로 변하고, 본문이 제거될 수 있음. (MUST)
TMI
- 처음 302 스펙의 의도는 HTTP method를 유지하는 것
- 그런데 대부분의 웹 브라우저들이 GET으로 바꿔버림(일부는 다르게 동작)
- 그래서 모호한 302를 대신하기 위해 명확한 307, 303이 등장 (301, 308도 마찬가지)
- 현실
- 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션들이 302를 기본값으로 사용
- 자동 redirection시 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음
기타 Redirection 300, 304
- 300 Multiple Choices : 안씀
- 304 Not Modified
- 클라이언트가 서버에게 “나 캐시 써도 돼?”
- 할 때 서버가 “써도 돼” 🆗 = 304 Not Modified & 캐시로 redirect
- 클라이언트가 로컬 캐시를 이용하므로 304 응답은 바디 없음
✈️ 4xx Client Error
- 오류의 원인이 클라이언트에게 있음
- 클라이언트가 잘못된 요청, 데이터를 보내고 있기 때문에 재시도 해봐야 실패함
4xx Client Error 종류
- 400 Bad Request
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
400 Bad Request
클라이언트가 잘못된 요청을 보내 서버가 요청을 처리할 수 없음
- 요청 구문, 메시지 등등 오류
- ex) 쿼리 파라미터 오류, API 스펙이 맞지 않음 ..
401 Unauthorized
해당 리소스에 대한 클라이언트의 인증이 필요함 (ex. 로그인)
- 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
참고
- Authentication (인증) : 본인이 누구인지 확인 (ex. 로그인)
-
Authorization (인가) : 권한 부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가)
- 오류 이름은 Authorization(인가)인데, 내용은 Authentication(인증). ???
403 Forbidden
서버가 요청을 이해했지만 승인을 거부
- 주로 인증 자격 증명은 있지만 접근 권한이 없는 경우 (찐 Unauthorized)
- ex) 일반 사용자가 관리자 등급의 리소스 접근
404 Not Found
요청 리소스를 찾을 수 없음
- 요청 리소스가 서버에 없음
- 권한이 없는 클라이언트에게 해당 리소스를 숨기고 싶을 때 (권한이 없다는 것도 알려주기 싫다는 심보?)
✈️ 5xx Server Error
- 오류의 원인이 서버에 있음
- 서버에 문제가 있기 때문에 클라이언트가 재시도 하면 성공할 수도 있음 (복구가 되거나 등등)
500 Internal Server Error
서버 문제로 오류 발생
- 애매하면 500 오류
503 Service Unavailable
서비스 이용 불가
- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
- Retry-After 헤더 필드로 복구까지 남은 시간 보낼 수 있음
✈️ Client & Server Error Tip
- 마음 약해져서 client error 봐주면 안됨 (나중에 일 커짐)
- 비지니스 로직으로 500 오류 내면 안됨. 500 server error는 진짜 심각할 때만
- 10대가 주류를 주문하는 것은 비지니스 로직 관점에서는 오류지만 정상적인 프로세스.
- 비지니스 로직은 HTTP 통신 오류가 아닌 다른 방식으로 처리
댓글 남기기