Computer Science/Web

Redirect와 Forward에 대한 간단 비교

TwinParadox 2020. 10. 28. 23:16
728x90

모든 내용을 언급하기 앞서 둘의 가장 큰 차이를 딱 하나로 말하라고 하면,

사용자에게(웹 브라우저에서) URL이 변경되어 보이는지 여부일 것이다.

 

Forward

Web Container에서의 페이지 이동만 진행되므로 웹 브라우저에는 해당 내용이 노출되지 않는다.

웹 브라우저에는 최초 호출 URL만 남아 있고, forward 과정에서 거쳐가는 URL은 노출되지 않으며, forward를 통해서 Request 객체와 Response 객체가 공유된다. 이러한 특성 때문에, 경우에 따라서 forward를 쓰면 문제가 발생할 수 있다.

 

예를 들어, 유저가 글쓰기나 삭제, 수정 과 같은 변경 작업을 요청으로 보냈고 그에 대해 응답을 할 수 있도록 forward로 응답 페이지를 불러온다고 가정하자. 이 과정에서 어떤 이유로든 응답 페이지에서 새로고침을 누르게 되면 Request와 Response는 그대로 존재하기 때문에 같은 변경 사항이 여러 차례 적용될 수 있다. 이런 문제를 감안하면, CREATE, UPDATE, DELETE 같은 수정 작업이 아니라 READ 같은 단순 조회 작업에 사용하는 것이 타당할 것이다.

 

  1. URL 변화를 볼 수 없다.
  2. Request 객체와 Response 객체를 공유하므로 forward를 진행하면 이 두 가지는 하나만 있다.
  3. Request/Response가 공유됨을 고려하여 READ와 같은 조회만 처리하는 것이 좋다.

 

Redirect

Web Container로 명령이 들어왔을 때, 웹 브라우저에게 다른 페이지를 요청할 것을 명령한다.

웹 브라우저는 redirect를 수행해야 하면 요청해야 되는 페이지의 URL로 새로운 요청을 진행하며, 다른 Web Container로 이동해 Request와 Response를 새로 생성한다.

 

이런 상황이라면, 이제 앞서 언급했던 상황에서의 forward의 문제는 redirect에서 더 이상 문제가 되지 않는다. forward는 응답 페이지가 Request와 Response가 남아 있어 문제가 됐지만, redirect는 해당 URL이 아닌 다른 URL에 새로운 Request와 Response가 생성되기 때문에 처음의 정보는 존재하지 않아 중복 작업이 발생하지 않는다. 결국 앞서 언급한 CRUD 중 CREATE, UPDATE, DELETE 작업은 redirect를 이용하는 것이 타당하다.

 

  1. URL 변화를 볼 수 있다.
  2. 웹 브라우저가 다른 URL에 새로운 요청을 보내는 것이기 때문에 Request, Response 객체를 공유하지 않는다.
  3. Request/Response를 공유하지 않기 때문에 CREATE, UPDATE, DELETE를 처리해도 된다.
728x90
728x90