리다이렉트와 포워드
특정 URL 접속 시 리다이렉트 또는 포워드가 일어나게 되면 작업 중인 페이지가 전환된다. 리다이렉트와 포워드는 페이지가 전환된다는 점에서 비슷한 역할을 한다. 하지만 이 둘 사이에는 페이지를 전환하는 주체가 다르다는 큰 차이점이 있는데, 이 차이점이 동작에 큰 영향을 미친다.
리다이렉트는 페이지 전환 주체가 클라이언트이며, 포워드는 페이지 전환 주체가 서버이다. 클라이언트가 주체가 되어 페이지를 전환하는 방법은 접속한 URL이 아닌 다른 URL로 직접 접속하는 방법 밖에 없다. 반대로 서버가 전환 주체가 되면 URL 주소가 바뀌지 않고도 서버 내부의 동작을 통해 다른 응답을 클라이언트에 내려줄 수 있게 된다. 리다이렉트와 포워드가 무엇인지, 어떻게 동작이 다른지를 살펴볼 것이다.
리다이렉트란?
리다이렉트(Redirect)는 서버에서 클라이언트에서 요청한 URL에 대 응답에서 다른 URL로 재접속 하라고 명령을 보내는 것을 말한다. Re-Direct는 'URL을 다시 가리킨다' 라는 뜻을 가지며, 클라이언트는 해당 URL로 다시 요청하게 된다. 리다이렉트가 일어나면 URL 주소가 바뀌면서 다시 접속되는 것을 확인할 수 있어, 클라이언트 또한 리다이렉션이 일어났음을 알 수 있다.
여기서 말하는 클라이언트는 보통 웹브라우저를 뜻한다. 웹브라우저는 서버에서 Redirect를 하라는 응답코드인 300번대 코드가 오게 되면, 리다이렉트를 해야되는 URL로 다시 요청을 보내는 역할을 한다.
그림1. 리다이렉트
예를 들어 [그림1]과 같이 클라이언트에서 kotlinworld.com/21를 서버에 요청했는데, 서버에서 해당 글이 kotlinworld.tech/2로 이동되었음을 확인한 경우 kotlinworld.tech/2로 리다이렉션을 명령하게 된다. 그러면 클라이언트는 다시 kotlinworld.tech/2를 요청하며, 서버는 해당 url 값의 html 문서를 리턴해 클라이언트에서 해당 문서를 확인할 수 있게 된다. 이때 웹브라우저 주소창의 kotlinworld.com/21이 kotlinworld.tech/2로 바뀌게 되어 클라이언트는 리다이렉션이 일어났음을 인지할 수 있다.
포워드란?
클라이언트가 한 번 더 요청을 보내도록 하는 리다이렉트와 다르게 포워드는 서버 내부에서 일어나는 호출이다. 클라이언트의 URL에 대한 요청이 들어오면 해당 URL이 다른 URL로 포워딩 된 것이 확인되었을 경우 서버에서 포워딩된 URL의 리소스를 확인하여 클라이언트에 응답한다.
포워딩이 일어나면 클라이언트 단에서는 아무런 동작을 하지 않으며, 모든 동작을 서버에서 처리한다. 따라서 클라이언트(웹브라우저)에서 요청한 URL은 물론 요청정보는 바뀌지 않는다.
그림2. 포워드
예를 들어 [그림2]와 같이 kotlinworld.com/95를 서버에 요청했는데, 서버에서 해당 글의 리소스가 kotlinworld.com/WEB-INF/95에 있음을 확인한 경우, kotlinworld.com/WEB-INF/95를 리소스를 확인하여 클라이언트에 응답하게 된다. 이 과정에서 클라이언트가 요청한 kotlinworld.com/95는 바뀌지 않고 요청 정보가 그대로 유지된다, 클라이언트 또한 포워딩이 일어났는지 조차 알지 못한다.
즉, 포워딩은 서버의 내부 동작이다.
리다이렉트와 포워드의 사용
사용자의 요청 정보가 바뀌어버리는 리다이렉트와 요청 정보는 그대로 유지한 체 서버 내부의 동작만 바뀌는 포워드는 적절히 사용되어야 한다.
리다이렉트는 클라이언트의 요청에 의해 서버의 DB에 변화가 생기는 작업에 사용된다. 예를 들어 DB의 유저 테이블을 변경하는 회원가입과 같은 경우에는 리다이렉트가 사용되어야 요청을 중복해서 보내는 것을 방지할 수 있다.
포워드는 특정 URL에 대해 외부에 공개되지 말아야 하는 부분을 가리는데 사용하거나 조회를 위해 사용된다. 스프링의 경우 /WEB-INF에 있는 view에 대한 정보들이 외부에 직접 공개되지 말아야 할 때 내부에서 포워딩을 통해 /WEB-INF 경로를 가리키도록 한다. 예를 들어 kotlinworld.com/95 로 요청을 하면 kotlinworld.com/WEB-INF/95를 응답하는 형식이다.
'Spring Framework' 카테고리의 다른 글
생성자 대신 builder(@builder)패턴을 사용해야 하는 이유 ! (1) | 2024.04.25 |
---|---|
Spring 404 JAVA 설정 예외처리 법 (0) | 2024.04.23 |
23.03.30 (0) | 2023.03.30 |