이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
일시적인 리다이렉션
=> 실무에서 정말 많이 사용한다.
302, 307, 303
- 302는 대부분 다 요청 메서드가 GET으로 바뀌기는 하지만, 100% 바뀐다고 장담은 못하기 때문에, 확실성을 위해서 303 코드가 나왔다.
- 303은 302과 같은 기능이지만, 100% 요청 메서드가 GET으로 변경 된다.
- 그러나, 실무에서는 아직도 302를 많이 사용하고 있다. 그리고 303 안쓰고, 302 써도 크게 문제는 없다.
그럼 이 일시적 리다이렉트를 언제 쓸까??
이게 실무에서 꼭 필요한 예가 있다.
처음에 웹 어플리케이션을 개발하다보면, 꼭 한 번은 직면하는 문제이다.
바로 PRG!!
만약에 "상품 주문하기" 버튼을 누르면, POST로 그 데이터가 넘어간다.
그 데이터가 남아있는 상태에서, 웹 브라우져를 새로 고침하면 어떻게 될까??
물론, 경고창을 한 번 보내겠지만, 그 POST 요청의 데이터가 한 번 더 서버로 들어가서 중복 주문이 발생할 수 있다.
다시 말해서, "새로 고침"도 POST가 되버린 거다.
이 문제를 해결하려면,
/order라는 페이지에 주문을 한다.
POST 요청을 통해서, 서버에 주문한 상품 ID와 수량을 message body에 담아서 보낸다.
서버는 해당 데이터를 저장한 이후에, 200 OK를 보내준다.
여기서 마지막 요청은 POST를 이용한 주문 요청이다.
그런데, 여기서 사용자가 실수로 "새로 고침" 버튼을 누른다면??
마지막 요청을 "새로고침" 하는 것이기 때문에, 동일한 POST 요청을 서버로 다시 한 번 보낸다.
사용자의 의도는 그저 화면을 새로고침 하려는 것뿐이었는데,
주문 데이터가 1 건이 더 들어온다.
그리고, 주문이 완료되서 클라이언트 쪽으로 200 OK가 한 번 더 날아온다.
만약, 클라이언트 측에서 계속 "새로 고침"하면 계속 주문이 들어갈 거다.
물론, 이런 상황은 서버에서 잘 막아야 한다.
그래도, 클라이언트 측에서도 한 번 더 막아주는게 좋다.
그게 PRG 패턴
- PRG 패턴 사용 전
클라이언트 차원에서 위와 같은 중복 주문을 방지할 수 있다.
사용성에서도 이게 훨씬 좋다.
POST로 주문 요청 후에, 결과 화면을 GET 방식으로 리다이렉트 하는 거다.
보통 주문이 됐으니까, 주문한 결과 화면을 GET으로 리다이렉트 하는 거다.
그래서, "새로 고침"이 일어나도 마지막 요청인 GET 요청이 일어나기 때문에, 결과 화면만을 렌더링한다.
- PRG 패턴 사용 후
/order라는 페이지에 주문을 한다.
POST 요청을 통해서, 서버에 주문한 상품 ID와 수량을 message body에 담아서 보낸다.
서버는 해당 데이터를 저장한 이후에, 302 Found나 303 See other를 보내면서, 주문이 생성된 Location을 같이 보내준다.
300대 상태 코드에 Location을 클라이언트의 브라우저는 자동으로 리다이렉트를 한다.
그리고 302 이기 때문에, 요청을 POST => GET으로 변경한다.
GET/ + Location으로 받은 URI 로 서버 측에 요청을 보낸다.
그러면, 서버 측은 주문 DB에 받은 내용을 저장하는 게 아니라 Location의 주문 정보를 조회해서 HTML 화면을 만들어서 200 OK 와 함께 message body에 실어서 보낸다.
만약, 여기서 사용자가 실수로 "새로고침"을 한다고 해도??
마지막 요청은 GET이기 때문에 그저 다시 한번 HTML 페이지를 받아서 렌더링 할 뿐이다.
이게 클라이언트 측에서 "중복 주문 문제"를 해결할 수있는 "일시적인 리다이렉트 방식인 PRG 패턴"이다.
이렇게 만들면, 사용성이 좋다.
다시 말해서, 사용자 입장에서도 실수로 "새로고침"을 해도 결과 화면이 보이는 거고다.
그리고 PRG 이전에, POST에서 "새로고침"하면 경고창이 뜬다. 그런 게 일단 사라져서 좋다.
또한, 서버 입장에서는 오류가 줄어든다.
사용자가 실수로 "주문 완료 페이지"에서 "새로 고침" 생각보다 많이한다.
그러면, 서버에서 이게 오면, 막아야 하는데, 같은 주문번호이면, 주문이 안되게 같이... 근데, 이거를 막으면, 막은 거 자체가 오류로 올라오기 때문에 이런 거까지 확 줄어든기 때문에, PRG 패턴은 모두에게 이롭다.
그래서 302, 303, 307 중에 뭘 써야 하나요??
기타 리다이렉션 - 300, 304
300은 안 쓴다!!
304는 진짜 많이 쓴다. 이 상태 코드는 나중에 "캐시" 정리할 때 더 자세하게 알아보자!!
=> 간단히 말해서, 304는 "캐시"로 리다이렉트한다.
