Forward 와 Redirect 방식의 차이

 

현재 작업 중인 페이지에서 어떤 요청으로 인해 다른 페이지로 이동할 경우 Forward 방식과 Redirect 방식 2가지 방식으로 페이지를 전환해준다.
두 방식의 공통점은 자신에게 요청이 왔을 때 자신이 처리할 수 없기 때문에 다른 URL에게 요청 처리를 위임한다는 점이다. 하지만 요청 처리를 위임하는 과정에서 차이점이 발생한다.

그렇다면 이 두 방식의 차이점은 무엇일까? 하나씩 알아보도록 하자.

 

 

1. Forward 방식

 

• Forward 방식은 URL 1에게 요청을 보내게 되면 해당 요청을 자신이 처리할 수 없기 때문에 다른 URL 2에게 직접 위임하여 처리하도록 하는 방식
• 서버 내부에서 처리하기 때문에 초기의 Request, Response 정보를 유지한 채로 전송된다.
• 또한, 서버 내부에서 일어나는 호출이기 때문에 클라이언트에게는 아무런 변화가 일어나지 않는다.
• 즉, 클라이언트는 초기에 접속한 URL 1의 정보를 제외한 실제로 요청을 처리해주는 URL 2의 정보를 알 수 없다.
• 또한, 서버 내부에서 동작하기 때문에 같은 웹 애플리케이션에 있는 페이지로만 이동이 가능하다.
• 클라이언트 요청을 정상적으로 처리했다는 의미로 HTTP 상태 코드 200을 나타낸다.

 

 

스프링 부트로 Foward 방식을 간단하게 테스트를 해본 결과는 다음과 같다.

@Controller
        public class ForwardController {
        
           @GetMapping("/url1")
            public String forward() {
                return "forward:/url2";
            }
        
            @GetMapping("/url2")
            public String forward2() {
                return "/forward";
            }
        }

 

 

/url1에 접속하게 되면 서버 내부에서 forward 방식을 통해 /url2의 페이지로 접속해주지만 주소창을 보면 /url2가 아닌 /url1이기 때문에 클라이언트는 /url1에 접속한 것으로 판단한다.

또한, Status Code가 200인 것도 확인할 수 있다.

 

 

 

 

 

 

2. Redirect 방식

 

 

• Redirect 방식은 URL 1에게 요청을 보내게 되면 해당 요청을 자신이 처리할 수 없기 때문에 Client에게 요청을 처리할 수 있는 URL 2에게 재요청하라고 URL 2의 정보를 응답해주면, Client는 URL 2에게 새로운 요청을 보내는 방식
• 새로운 요청을 보내기 때문에 Request 1과 Request 2는 전혀 다른 요청이다.
• 따라서 클라이언트는 URL의 변화를 알 수 있다.
• 또한, 서버 내부에서 동작하는 Forward 방식과 달리 새로운 요청을 보내기 때문에 다른 웹 애플리케이션에 있는 페이지로도 이동이 가능하다.
• 클라이언트 요청한 URL가 일시적으로 변경되어 원래의 URL로 요청해야 한다는 의미를 가지는 HTTP 상태 코드 302를 나타낸다.

 

스프링 부트로 Redirect 방식을 간단하게 테스트를 해본 결과는 다음과 같다.

 

@Controller
        public class RedirectController {
        
            @GetMapping("/url1")
            public String redirect() {
                return "redirect:/url2";
            }
        
            @GetMapping("/url2")
            public String redirect2() {
                return "/redirect";
            }
        }

 

 

 

/url1에 접속하게 되면 서버 내부에서 Redirect 방식을 통해 /url2의 페이지로 다시 접속해주는 것을 확인할 수 있다. 그 증거로 주소창에는 /url2로 접속하였다는 것을 알 수 있다.

또한, Status Code가 302인 것도 확인할 수 있다.

 

 

두 방식의 차이점을 확인하였다. 그렇다면 언제 어떤 방식을 사용해야 하는 것일까?

결론부터 말하자면 Get 방식처럼 단순히 조회하는 요청은 Forward 방식을 사용하고 Post, Put 방식처럼 무언가를 변화시키는 요청에는 Redirect 방식을 사용해야 한다.

기본적으로 Forward 방식이 Redirect 방식보다 성능상 좋다. 왜냐하면 Forward 방식은 서버에서만 처리되지만 Redirect 방식은 클라이언트와 통신이 한 번 더 발생하기 때문이다.

또한, Redirect 방식으로 처리하면 클라이언트 입장에서 화면이 전환되는 이벤트를 감지할 수 있기 때문에 일반적인 경우는 Forward 방식으로 처리해주는 것이 낫다.

 

하지만 Post, Put 같은 무언가를 변화시키는 요청에는 Redirect 방식을 사용해야 한다.

왜냐하면 클라이언트가 Post 요청으로 무언가를 변화시킨 후 실수로 새로고침을 눌러버리면 웹 브라우저에서 새로고침은 마지막에 서버에 전송한 데이터를 다시 전송하기 때문에 다시 URL에 접속되면서 Post 요청이 한번 더 전송되기 때문이다.

상품 등록 요청을 하였는데 재요청을 보내버리면 2개의 상품이 중복 등록가 돼버리는 상황이 발생하게 된다.

 

 

이를 해결하기 위한 방법이 바로 Redirect를 활용하는 PRG(Post/Redirect/Get) 방식이다.

상품 등록 요청이 발생하면 Forward 방식으로 상품 저장 뷰를 보여주는 것이 아닌 상품 상세 화면으로 Redirect를 호출해주면 된다.

웹 브라우저는 Redirect의 영향으로 마지막 요청이 상품 상세 화면으로 이동하는 요청이기 때문에 새로고침을 눌러도 Get 방식으로 상품 상세 화면을 요청하게 된다.

 

 

 

 

---

출처 - https://sorjfkrh5078.tistory.com/271