| forward | redirect | |
| 주소 표기 | 사용자는 “a.do”를 요청했고, 컨트롤러에서는 return “forward:/b.do”라고 하여 “b.do”의 처리결과를 브라우져에 보이게 된다.하지만, 사용자의 브라우저에는 최종처리된 “b.do”가 나타나는 것이 아니라 애초 요청한 “a.do”가 나타나게 된다. | 사용자는 “a.do“를 요청했고, 이를 처리한 컨트롤러가 return “redirect:/b.do”라고 하면웹서버는 redirect에 지정된 URL(b.do)을 클라이언트(브라우져)로 보낸다. URL(b.do)를 수신한 브라우져는 해당 URL(b.do)을 이용하여 별도의 서비스를 요청한다. 이때 b.do라는 서비스 요청을 브라우저 내부에서 수행하므로 사용자는 인식하지 못한다. |
| 데이터 호환 | 사용자의 요청 a.do를 처리하는 과정에 가공된 request, response들을 b.do를 처리하는 컨트롤러에서 모두 사용가능하다. | redirect되는 url(b.do)는 브라우져가 별도로 서비스 요청을 하게 되므로, 애초에 요청했던 url(a.do)를 처리하는 과정에서 사용하던 request, response 관련 정보는 소멸되고, 새로운 서비스요청(b.do)에 해당하는 request, response는 새롭게 만들어지게 된다.즉, a.do의 request, reponse는 b.do를 처리하는 과정에서 일체 사용할 수 없게 된다. 사용을 하려 한다면 b.do에 파라매터 전달방식(문법)을 통해 전달해야한다. |
| 지정가능 페이지 | 위 데이터 호환에서 설명한 바와 같이 a.do의 처리과정에서 가공중인(또는 가공된) 메모리상의 response, request를 b.do에서도 모두 사용가능하다고 했으니 물리적/논리적으로 분리된 웹 컨테이너라면 공유가 불가능할 것이다.고로 지정가능 페이지는 a.do를 포함하는 웹 컨테이너에 속한 URL만 지정가능하다. | a.do라는 url을 처리하고, 브라우져에 b.do를 보낸뒤 브라우져가 다시 b.do라는 서비스를 요청하므로 redirect되는 URL은 현재 a.do를 처리하는 웹 컨테이너와 무관하게 유효한 URL이라면 모두 사용가능하다 |
[출처] http://blog.daum.net/janustop/128