일시적인 리다이렉션
302, 307, 303
-리소스의 URI가 일시적으로 변경
-따라서 검색 엔진 등에서 URL을 변경하면 안됨
302 Found
-리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
307 Temporary Redirect
-302와 기능은 같음
-리다이렉트시 요청 메서드와 본문 유지
303 See Other
-302와 기능은 같음
-리다이렉트시 요청 메서드가 GET으로 변경
PRG: Post/Redirect/Get
일시적인 리다이렉션 - 예시
- POST로 주문 후에 웹 브라우저를 새로고침하면?
- 새로고침은 다시 요청
- 중복 주문이 될 수 있다.
/order 폼에다가 데이터를 입력후 POST 메서드로 전송한다.
서버는 주문데이터를 저장하고 200 OK 보낸다.
혹시 새로고침을 누르게 되면 또다시 서버는 주문 데이터를 저장하게된다.
주문완료 200 OK를 보낸다. 새로고침을 할 때마다 주문을 여러개 하게 된다.
이러한 문제를 해결하기 위해서 PRG를 사용한다.
PRG: Post/Redirect/Get
일시적인 리다이렉션 - 예시
- POST로 주문후에 새로 고침으로 인한 중복 주문 방지
- POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
- 새로고침해도 결과 화면을 GET으로 조회
- 중복 주문 대신에 결과 화면만 GET으로 다시 요청
POST 메서드로 폼에 데이터를 넣고 요청을함
데이터베이스에 상품이 쌓인다.
이때 응답을 302 Found와 Location 정보를 준다. /order-result/19
클라이언트는 302코드를 보고 리다이렉트를한다. GET메서드 사용
서버는 주문 결과를 보내고 (200 OK)
이렇게되면 새로고침을 아무리한다고 해도 GET메서드 덕분에 다시 결과를 보게된다.
PRG 이후 리다이렉트
- URL이 이미 POST -> GET으로 리다이렉트 됨
- 새로고침해도 GET으로 결과 화면만 조회
그래서 뭘 써야할까?
302, 307, 303
정리
302 Found -> GET으로 변할 수 있음
307 Temporary Redirect -> 메서드가 변하면 안됨
303 See Other ->메서드가 GET으로 변경
역사
- 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것
- 그런데 웹 브라우저들이 대부분 GET으로 바꾸어버림
- 그래서 모호한 302를 대신하는 명확한 307, 303이 등장
현실
- 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
- 자동 리다이렉션시에 GET으로 변해도 되면 302를 사용해도 큰 문제 없음
기타 리다이렉션
300, 304
300 Multiple Choices : 안쓴다.
304 Not Modified
- 캐시를 목적으로 사용
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다.
- 304 응답은 응답에 메시지 바디를 포함하면 안된다.
- 조건부 GET, HEAD 요청시 사용
'웹프로그래밍 > 웹 기본 지식' 카테고리의 다른 글
| 24. HTTP 헤더 개요 (0) | 2022.01.12 |
|---|---|
| 23. 4xx - 클라이언트 오류 / 5xx - 서버 오류 (0) | 2022.01.12 |
| 21. 3xx - 리다이렉션 (0) | 2022.01.11 |
| 20. 2xx - 성공 (0) | 2022.01.11 |
| 18. HTTP API 설계 예시 (0) | 2022.01.10 |