[Network] HTTP 상태 300 응답값 정리 by 김영한님 (Rowen Jobs)

HTTP 상태 300 응답값 정리

 
요청을 완료하기 위해 유저 에이전트(클라이언트)의 추가 조치 필요
 
영구 리다이렉션 - 특정 리소스의 URI 가 영구적으로 이동
 
301(드물게 보임)
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수도 있음
- 예를들어 등록할려고 POST 방식으로 Body에 값을 넣어 보냈는데 해당 URL 은 사용하지 않아 
   리다이렉트가 되고 GET으로 자동 변경되어 새로운 URL 을 요청하는데 이때 POST때 넣은 BODY는 없다. 
   변경된 GET URL 에서 새로 작업을 하여야 한다.
 
클라이언트 - 서버 - 클라이언트 - 서버 - 클라이언트 순으로 진행되고 아래를 참고하면 된다.
클라이언트 - 옛URL, Body 값 -> 서버
클라이언트 <- 301 : GET 변경, Body 값 없다. <-서버
클라이언트 -> 리다이렉트 한 GET  -> 서버
 
308(거의 못봄)
- 301과 동일하게 자동 리다이렉션이 되는데 요청메서드가 POST 로 변경이 된다.
 
일시 리다이렉션 - 일시적 변경/ 주문 완료 후 주문 내역 화면 이동
 
302 
- 301과 동일하게 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수도 있음
 
307
- 302와 기능은 같다.
- 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.절대)
 
303
- 302와 기능은 같다
- 명확하게 리다이렉트시 요청 메서드가 GET으로 변경
 
PRG: Post/Redirect/Get
문제점 
POST 주문 -> 주문완료 200-> 새로고침 -> 중복주문
해결
POST 주문 -> GET 메서드로 리다이렉트 (GET 화면만 계속 새로고침상태로 된다.) -> GET 으로 요청 -> DB 데이터 출력만 됨
 
간단 정리
302 -> 대부분 GET 메서드로 변경
307 -> POST 로 메서드 변경
303 -> 무조건 GET 으로 변경
303, 307 을 사용하는게 가장 좋으나 현재 302로  많고 리다이렉션이 GET로 가도 괜찮으면 302 도 사용해도 괜찮다.
 
 
특수 리다이렉션 - 결과 대신 캐시를 사용 
300, 304
 
300은 안쓴다
 
304 는 많이 사용한다. 
캐시를 목적으로 사용하고 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 
따라서 클라이언트는 로컬 PC 에 저장된 캐시를 재사용한다.(캐시로 리다이렉트)
 
304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)
 
조건부 GET, HEAD 요청시 사용

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard