Aug 3, 2021 - HTTP 상태 코드, PRG, Redirection

*8월3일

 

 

*각종 HTTP 상태 코드

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

 

1)1xx informational : 요청이 수신되어 처리중; 거의 사용되지 않음

 

 

2)2xx successful : 요청 정상 처리

 

200 OK  //get방식 조회에 대한 응답

201 Created //post 방식으로 데이터 전달하고 서버에서 리소스 생성

202 Accepted //요청이 접수 되었으나 처리가 완료되지 않음. 예를 들어 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 구조

204 No Content //서버가 요청을 성공적으로 수행했지만, 응답 본문에 보낼 데이터가 없음. 예를 들어 웹문서 편집기에 save 버튼

 

3)3xx redirection : 요청을 완료하려면 클라이언트(웹브라우저)의 추가 행동이 필요;

 

Redirection

-정의 : 웹브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동함. 이를 바로 리다이렉션이라고 함.

-절차 : Client측에서 get방식 /event 요청 -> Server 측에서 301 moved permanently와 함께 location header에 /new-event 응답 -> 브라우저 자동 리다이렉트 -> Client에서 자동으로 /new-event 요청 -> Server측에서 200 ok 응답

-종류 : 영구 리다이렉션은 특정 리소스의 URI가 영구적으로 바뀜 / 일시 리다이렉션은 주문 완료 후, 주문 내역화면으로 이동하는 경우(PRG : Post -> Redirect -> Get) / 특수 리다이렉션은 결과 대신 캐시를 사용하는 경우, 추가 다운 없이 캐시에서 리소스 그대로 사용

 

301,308 영구 리다이렉션(실무 사용 비율 낮음)

-원래 URL을 사용하지 않음. 검색 엔진 등에서도 변경 인지

-301 moved permanently은 리다이렉트 시 요청 메소드가 GET으로 변하고 본문이 제거될 수 있음; 클라이언트 측에서는 처음 적었던 데이터 다시 입력 필요...

-308 permanent redirect은 301과 기능은 같지만 리다이렉트시 요청 메소드와 본문 유지하는 케이스(처음 POST면 리다이렉트 후에도 POST); 클라이언트 측에서는 기존 데이터가 유지 되기에 다시 적을 필요 없음;

 

302, 307, 303 일시적 리다이렉션(실무에서 자주 사용)

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

-302 Found 리다이렉트 시 요청 메소드가 GET으로 변하고, 본문이 제거 될 수 있음 //대부분의 framework default 값, 사용 비율 높음

-307 temporary redirect는 302와 기능이 같고, 리다이렉트 시 요청 메소드와 본문 유지 해야 함!

-303 see other는 302와 기능은 같고, 리다이렉트 시 요청 메소드가 get으로 변경

 

PRG : post/redirect/get

-POST로 주문 후 웹 브라우저를 새로고침하면?

-PRG 사용하지 않으면, 새로고침은 다시 요청 처리 되어, 중복 주문이 될 수 있다.

->주문 번호 기준으로 필터해서 서버에서 실질적으로 막아줘야함. 주문서 작성 시 주문 번호 신규 생성 -> 새로고침해도 동일한 주문서이기에 주문번호도 같을 것임.

 

-PRG 사용하면, post로 주문 후에 새로고침으로 인한 중복 주문 방지 가능. 

->post로 주문서 요청 itemid=mouse&count=1 -> 서버에서는 접수하여 DB에 주문 데이터 저장 후, 302 found로 응답줌 location : /order-result/19 -> 클라이언트 브라우저가 자동 리다이렉트하여 get으로 메소드 변경 /order-result/19 -> 서버에서는 해당 내용 접수 받아서 200ok 전송 -> 클라이언트 측에서는 새로고침하여도 해당 get에 대한 결과 화면만 다시 요청하여 중복 주문 방지

 

기타 리다이렉션 300 304

-300 multiple choices는 잘 안씀.

-304 not modified는 캐시를 목적으로 사용. 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. 즉, 캐시로 리다이렉트 하는 케이스. 로컬 캐시를 재사용하므로 응답에 메시지 바디를 포함하면 안됨!!

 

4)4xx client error : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음. 오류의 원인이 클라이언트에 있음.

 

-클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 재시도가 실패함. 즉, 서버 사이드에서 복구 불가능!

-400 bad request는 클라이언트가 잘못된 요청을해서 서버가 처리할 수 없음. 요청 구문, 메시지 등 오류. 요청 파라미터가 잘못되거나 API 스펙이 맞지 않을 때

-401 unauthorized는 클라이언트가 해당 리소스에 대한 인증이 필요한 경우; 로그인이 안된 케이스가 예시

-403 forbidden은 서버가 요청을 이해했지만 승인을 거부함. 인증자격은 있지만 접근 권한이 없는 경우임. 일반 계정으로 admin 권한 접근

-404 not found 요청 리소스가 서버에 없음 또는 클라이언트가 권한이 부족한 리소스에 접근 시, 해당 리소스를 숨기고 싶을 때도 사용

 

5)5xx server error : 서버오류, 서버가 정상 요청을 처리하지 못함. 서버에 문제가 있기에 재시도하면 성공할 수도 있음(null point 등등..)

 

-500 internal server error 백엔드에서 애매한 오류는 거의 대부분 500 오류

-503 service unavailable은 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음. Retry-after로 헤더 필드에 얼마 뒤에 복구되는지 보낼 수 있음.

-고객의 잔고 부족이나 나이 제한에 걸렸을 시에는 500에러를 내면 안된다! 클라이언트 단에서 걸러줘야함! 500은 심각한 서버에 문제가 있을 때만 발생 해야 함.