리다이렉트 (Redirect)

 

 

💡 리다이렉션(Redirection) 이해하기

 

먼저 리다이렉트란,

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동하는 것을 의미한다.

리다이렉션에는 크게 3가지 종류가 있다.

1. 영구 리다이렉션
- EX) /members  —>  /users
- EX) /event  —>  /new-event

→ 리소스의 URI가 영구적으로 이동
→ 원래의 URL을 더이상 사용 X, 검색 엔진 등에서도 변경 인지

→ ex) 301, 308

2. 일시 리다이렉션 (실무에서 많이 사용됨)
- EX) 주문 완료 후 주문 내역 화면으로 이동해야 하는 경우
→ PRG : Post/Redirect/Get

→ 리소스의 URI가 일시적으로 변경
→ 따라서 검색 엔진 등에서 URL을 변경하면 안됨
→ ex) 302, 307, 303

3. 특수 리다이렉션
- 결과 대신 캐시를 이용

 

 

 

 

 

📍 일시적 리다이렉션 대표 예시) PRG : Post/Redirect/Get

만약 POST로 상품을 주문을 한 후, 웹 브라우저를 새로 고침 한다면?

POST에 데이터가 한번 더 들어가게 되어서 서버에 중복 주문이 들어갈 수 있다 !!

새로 고침도 POST가 되어버린 것이다 !! 내가 요청했던 것을 새로 고침 해버린 것이다.

왜냐하면 마지막으로 보낸 것이 PSOT이기 때문에 웹 브라우저도 내가 새로 고침을 하면

그 POST 요청을 한번 더 해주게 되는 것이다.

 

이럴 때 PRG 패턴을 사용하면 해결 할 수 있다!!

 

 

 

PRG 사용 전

 

 

 

PRG 사용 후

 

 

POST로 주문한 후에 새로 고침으로 인한 중복 주문 방지가 된다.

POST로 주문한 후에 주문 결과 화면을 GET 메서드로 리다이렉트를 해준다.

새로고침을 해도 결과 화면을 GET으로 조회하는 것이 된다.

→ 중복 주문 대신에 결과 화면만 GET으로 다시 요청하게 되는 것이다!!

 

>> PRG 이후 리다이렉트 <<

→ URL이 이미 POST에서 GET으로 리다이렉트 된다.

→ 새로 고침을 해도 GET으로 결과 화면만 조회된다.

 

 

 

 

 

 

 

그래서 일시적 리다이렉트 302, 307, 303 어떤 것을 써야 하나요?

정리

• 302 Found → GET 으로 변할 수 있음
• 307 Temporary Redirect → 메서드가 변하면 안됨
• 303 See Other → 메서드가 GET으로 변경

역사

• 처음 302 스펙의 의도 : HTTP 메서드를 유지하는 것
• But, 웹 브라우저들이 대부분 GET으로 바꾸어버림 (일부는 다르게 동작)
• 그래서 모호한 302를 대신하는 명확한 307, 303 이 등장하게 됨 (301 대응으로 308도 등장함)

현실

• 307, 303을 권장
• But, 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용함
• 자동 리다이렉션 시, GET으로 변해도 되면 그냥 302를 사용해도 무방하다!!