멀티캠퍼스 [현대 이지웰] URI와 URL 뭐가 다른거야!

 

 

URI(Uniform Resource Identifier)

리소스를 식별하는 통합된 방법

- Uniform은 리소를 식별하는 통일된 방식

- Resource란, URI로 식별이 가능한 모든 종류의 자원(웹 브라우저 파일 및 그 이외의 리소스 포함)을 지칭함

- Identifier는 다른 항목과 구분하기 위해 필요한 정보

 

즉, URI는 인터넷상의 리소스 '자원 자체'를 식별하는 고유한 문자열 시퀀스이다.

 

URL(Uniform Resource Locator)

특정 자원의 '위치'를 가리키는 URI의 한 종류

- 네트워크상에서 통합자원(리소스)의 '위치'를 나타내기 위한 규약

즉, 자원 식별자와 위치를 동시에 보여준다.

특정 웹 페이지의 주소에 접속하기 위해서는 웹 사이트의 주소뿐만 아니라 프로토콜(https, http, sftp 등)을 함께

알아야 접속이 가능하다. 이들을 모두 나타내는 것이 URL이다.

 

 

URI는 그 자체로 이름이 될 수 있다.

naver.com -> URI

https://www.naver.com -> URL, URL

URI는 그 자체로 이름이거나, 이름 + 위치를 나타낸 형태 모두가 해당된다.

식별자 + 위치를 나타내는 URL은 URI에 종속되어져있다.

 

이렇게 사진으로 보면 더 명확하게 알 수 있다.

여기서 더 자세히 나눠보자

 

 

Scheme는 리소스에 접근하는 데 사용할 프로토콜이다. 웹에서는 http 또는 https를 사용한다.

프로토콜이란?
컴퓨터나 네트워크 상에서 데이터를 주고받기 위한 약속(규칙)이다.
사람 간의 대화에서 '언어'가 필요하듯, 컴퓨터 간의 통신에서도 정해진 규칙이 필요하다.
문법, 의미, 순서를 정해 통신한다.

 

 

 

Host는 접근할 대상(서버)의 호스트 명이다.

 

Path: 접근할 대상(서버)의 경로에 대한 성세 정보다.

* 경로(Path)에 해당하는 부분은 URN이라고 한다.

URN이란?
리소스의 위치, 프로토콜, 호스트 등과는 상관없이 각 자원에 이름을 부여한 것이다.
즉 URL은 어떤 특정 서버에 있는 웹 문서를 가리키는 반면, URL은 웹 문서의 물리적인 위치와 상관없이 웹 문서
자체를 나타낸다.

 

 

 

주의점

- 쿼리(?)는 서버로그에 남을 수 있다.

?seq=40 이런 형태의 URI를 볼 수 있다. 이것은 쿼리스트링이라는 것이다.

HTTP 요청 라인의 일부로 서버에 전달되고, 웹서버/프록시/로드밸런서/애널리틱스 툴의 로그에 기록될 가능성이 높다.

또한, 브라우저의 주소창, 히스토리, 북마크 Referer 헤더에도 남을 수 있다.

절대 쿼리로 민감정보를 전송하면 안 된다!

 

Context path

- 웹 애플리케이션을 구분하기 위한 고유한 경로(prefix)

하나의 서버에는 여러 웹 애플리케이션을 배포할 수 있는데 이때 각각을 식별하기 위해 context path를 사용한다.

즉, 도메인 뒤에 붙는 첫 번째 경로가 보통 context path다.

 

 

도메인: localhost:8080

context path: /myapp

실제 요청경로: /hello

 

Scheme: http://

Host: localhost:8080/

path: /myapp/hello

 

DispatcherServlet 같은 프론트 컨트롤로거 실행되기 전에, 서버가 context path를 기준으로 요청을 어느 앱에 보낼지 결정한다.

이제 코드를 살펴 보겠습니다.

 

form 태그의 action 속성

action은 폼 데이터를 전송할 URL을 지정합니다.

metho="post" 이므로 입력된 값이 HTTP POST 요청의 body에 담겨서 해당 URL로 전송됩니다

 

${contextPath}의 의미는 JSP/서블릿에서 제공하는 표현 언어(EL) 문법입니다.

여기서 contextPath는 현재 웹 애플리케이션의 컨텍스트 경로 값을 의미합니다.

ex) 애플리케이션이 /myapp이라는 context path로 배포됐다면 ${contextPath}는 /mapp이 됩니다.

 

서버 주소가 http://localhost:8080이고, 애플리케이션 context path가 /myapp이라면

action="${contextPath}/User/deluser.do" 는 실제 요청 URL로 변환되어 아래 사진 처럼 됩니다.

/User/deluser.do는 보통 서블릿 매핑 주소입니다.

즉, 이 URL을 처리할 컨틀로러/서블릿이 존재해야 하고, 거기서 전달된 userId와 password를 꺼내서 회원 삭제 로직을 수행하게 됩니다.

 

그러면 왜 ${contextPath}를 쓸까?

- 하드코딩 방지

만약 HTML에서 /myapp/User/deluser.do처럼 직접 context path를 적어두면, 애플리케이션이 다른 이름으로 배포될 때(URL이 바뀔 때) 전부 수정해야 합니다.

- 재사용성 확보

${contextPath}를 쓰면 어느 서버, 어느 경로에 배포되더라도 자동으로 현재 경로에 맞춰 요청이 들어가므로 유지보수에 유리합니다.

 

 

위 사진처럼 /User/* 에 해당하는 컨트롤러에 요청이 들어오게 됩니다.

 

그리고 이곳에 전달되어 if문 안에 있는 로직을 실행하고 다시 다음 페이지를 넘기게 됩니다.