URL이 자체 웹 응용 프로그램에있는 경우 사람들이 왜 리디렉션해야합니까? Spring에서 컨트롤러의 핸들러 메소드를 동일한 컨트롤러의 다른 핸들러 메소드로 리디렉션하는 이유는 무엇입니까? 리디렉션은 브라우저 기반이라고 들었습니다. 다른 URL로 요청을 보내려면 브라우저에 요청을 보내는 것과 같습니다. 브라우저의 윈도우에있는 URL이 동일하게 유지되도록 (spring mvc) 응용 프로그램 내에서 forward가 사용되는 것처럼 앞으로 나아갈 수 있습니다.스프링 MVC에서 리디렉션을 사용하는 이유는 무엇입니까?
그러나 그것은 영웅 리디렉션을 사용하는 것입니다 : 당신은 단순히 뷰 이름을 보내거나 필요가있을 경우 앞으로 사용할 수 있습니다/URL입니다.
특정 컨텍스트가 없으면 일부 핸들러가 실행 된 후 리디렉션을 사용하는 이유를 모두 설명하기 어렵습니다.
는 (예를 들어, POST 후) 핸들러 처리 후의 리디렉션이 원하는 디자인 패턴 간주되는 상황이있다 - POST/Redirect/GET.
하나의 공통적 인 문제는 POST 방법을 사용한 중복 양식 제출입니다. 양식을 처리 한 후 리디렉션을 사용하면 응용 프로그램이 대부분 새로 고침 된 URL에 있으므로 사용자가 새로 고침하고 양식을 다시 제출하지 못하게 할 수 있습니다.
컨트롤러에 redirect이라는 접두어를 사용하면 302 상태 코드와 리디렉션 URL을 가리키는 위치 헤더가있는 HTTP 응답이 생성됩니다. 그러면 브라우저가 해당 URL로 리디렉션됩니다 (첫 번째 요청에서 노출 된 모델은 손실되고 브라우저 URL은 두 번째 요청이됩니다).
접두사 forward을 사용하면 전달은 서블릿에 의해 내부적으로 수행되므로 두 번째 요청 (URL은 동일하게 유지됨)이 필요하지 않습니다. forward 접두사는 브라우저에 의해 안전하게 반복 될 수있는 요청 인 에서만 사용해야합니다. 데이터베이스 상태를 변경하는 양식을 보낼 때 (브라우저를 다시로드하면 중복 제출 될 수 있음)에는 해당되지 않습니다. 이 경우 redirect을 사용하고 POST-redirect-GET 패턴을 적용해야합니다. 우리는 페이지로 리디렉션 대신 앞으로 할 http://en.wikipedia.org/wiki/Post/Redirect/Get
에 우리는 우리의 양식 제출에 리디렉션 - 후 - 후 패턴을 적용 할 때문에 참조하십시오. 이 패턴에서
는 성공적인 양식을 제출하는 경우 사용자가 다시로드 또는 북마크 페이지 다시 제출을 피하기 위해 HTTP 리디렉션을 발행합니다.