[Http] 상태 코드 정리

http 상태 코드 정리

 

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

 

만약 모르는 상태코드 또는 미래에 새로 추가될 상태코드 (ex. 299) 가 온다면 위의 큰 범위로 생각해서 처리하면 된다. 

 

 

1. 1xx (Informational) 

거의 사용하지 않으므로 생략 

 

 

2. 2xx (Successful) 

200 : OK - 주로 get 에 대한 성공적인 결과로 주는 응답 

201 : Created - 주로 post로 등록할 때 서버쪽에서 리소스를 생성한 경우

202 : Accepted - 요청이 접수되었으나 아직 처리 완료되지 않음 (ex. 한 시간 뒤 서버에서 배치 돌릴 때)

204 : No Content - 서버가 요청을 성공적으로 수행했으나 응답 페이로드 본문에 보낼 데이터가 없는 경우 

 

개발할 때 각 팀 내부에서 "성공" 여부의 범위를 보통 잡는다고 한다. 안그러면 너무 많은 상태 코드가 사용됨! 

 

 

3. 3xx (Redirction) 

 

* 리다이렉션이란 ? 

: 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 적힌 location 위치로 자동 이동한다. 

1) 영구 리다이렉션 : uri 영구적으로 이동된 경우

2) 일시 리다이렉션 : 일시적인 변경  ex. 주문 완료 후 주문 내역 화면으로 이동

       ex) PRG: Post/Redirect/Get 

       - post로 주문 후에 웹 브라우저를 새로고침하면 ? - 또 요청 보내짐

       - 이를 해결하려면 : (서버에서 한 번 막긴 하지만) 클라이언트 쪽에서 또 막는 방법이 PRG 요고 

       - 주문 결과 화면을 GET 메서드로 리다이렉트 (302 or 303 )----> 새로고침해도 계속 GET 조최 -> 중복 요청 방지 가능 

3) 특수 리다이렉션 : 결과 대신 캐시를 사용 ex. 클라이언트가 캐시 기간이 만료된 것 같아 서버에 만료된거 맞아 ? 서버에 물어보면 서버가 캐시 문제 없어 캐시 다시 조회해~ 라고 응답 보내는 경우 

 

 

300 : Multiple Choices - 거의 안씀

 

301 : Moved Permanently

- 이전 url이야 완전히 안쓰니까 Location에 적은 위치로 가 ! -> 웹 브라우저는 다시 uri요청해야 함 / 리다이렉트 시 요청 매서드가 GET으로 변하고 본문이 제거될 수 있음 (보통) (MAY) => 다시 처음부터 등록하려던 데이터를 시작해야 함 

Client ---- POST 요청 with data -----> Server

Client <--- 301 / Location: /new-uri --- Server

Client ---------  GET 요청 -----------> Server

Client <--------- 200 응답 ------------ Server 

Client ------- POST 요청 with data----> Server

 

302 : Found 

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

 

303 : See Other

- 302와 기능이 같음

- 리다이렉트 시 요청 메서드가 GET으로 변경 (명확 MUST)

 

304 : Not Modified 

- 캐시를 목적으로 사용, 굉장히 많이 씀 

- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. -> 그럼 클라이언트는 로컬pc에 저장된 캐시를 재사용한다. ( = 캐시로 리다이렉트)

- 304 응답은 "body"를 포함하면 안된다. (로컬 캐시를 사용할 거니까) 

- 조건부 GET, HEAD 요청 시 사용

 

307 : Temporary Redirect 

- 302와 기능이 같음

- 리다이렉트 시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안된다. MUST NOT) 

 

308 : Permanent Redirect

- 301과 기능은 같음 / 리다이렉트 시 요청 메서드와 본문 유지 

Client ------- Post 요청 with data -------> Server

Client <----- 308 : Location: /new-uri ---> Server

Client ------- Post 요청 with data --------> Server

Client <------------ 200 응답 ------------- Server

 

301 vs 308 실무에서는 보통 301을 사용한다고 한다. uri가 변경되었다는 것은 내부적으로 전달해야 하는 데이터도 많이 바뀌어서 아예 get 요청으로 다시 해줘! 가 낫다고 한다.  

 

302 vs 303 vs 307 중에서는 아직까지 302를 많이 쓰고 있다고 함 

 

 

 

 

4. 4xx (Client Error)

- 클라이언트 오류 

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

   ex) 요청 파라미터 실수, API 스펙 안 맞을 때 등

- 계속해서 재시도하더라도 실패함 (왜냐하면 이미 요청 자체에 문제가 있으니)

 

 

401 : Unauthorized 

- 클라이언트가 해당 리소스에 대한 인증이 필요함 (인증관련이지만 Unauthorized 점 주의) 

 

Authentication (인증 : 로그인, 본인이 누구인지 확인) 

Authorization (인가 : 권한부여) 

 

403 : Forbidden 

- 서버가 요청을 이해했지만 승인을 거부함 

- 인증 자격 증명은 있지만 접근 권한이 불충분 

 

404 : Not Found 

- 요청 리소스를 찾을 수 없음 

- 클라이언트가 권한이 부족한리소스에 접근했을 때 사이트 없다고 숨기고 싶을 때 

 

 

 

 

5. 5xx (Server Error)

- 클라이언트가 똑같은 요청을 보낼 때 언젠가 성공할 가능성이 있음 (서버 내부의 문제가 수정된 경우)

 

500 : Internal Server Error

- 서버 내부 문제로 오류 발생

- 애매하면 500 오류 

 

503 : Service Unavailable 

- 서비스 이용 불가 

- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없을 때 

- Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있음 

=> 하지만 예측 불가한게 대부분이라 보통 500으로 함 

 

 

 

Reference : 인프런 <모든 개발자를 위한 http 웹 기본 지식>