URI = URL + URN

URI = Uniform Resource Identifier (통합 자원 식별자)

URL = Uniform Resource Locater (통합 자원 위치 표시)

URN = Uniform Resource Name(통합 자원 이름)

URI는 URL과 URN을 합친 개념이다.

URL은 어떤 인터넷상에서의 자원(이미지파일,HTML파일등등..)의 위치를 표시하기 위한 어떤 주소라고 생각하면 쉽다.

그럼 URI라는것은 왜 필요한지 생각해보자.

요즘은 웹 서버뿐만 아니라, 웹어플리케이션 서버라는것도 존재한다.(WAS) 이 WAS는 어떤 사용자가 URL을 통해서 서버에 명령을 내렸을때 그에 해당하는 로직을 수행한뒤 나온 결과를 다시 사용자에게 되돌려주어야 하는 역할을 갖는다.

이럴때 사용하는 주소(사용자가 입력한 주소)는 URL이라고 표현하기엔 애매하다. 왜냐면, 이것은 정적인 자원(이미지나 텍스트파일 같은)이 아니고 동적인 자원(어떤 서버 프로그램)이기 때문이다.

그렇기 때문에 URI라는 URL의 상위 개념이 필요한것이다.

즉 어떤 사용자가 http://www.naver.com/login.do 라는 URI를 입력했을때 naver의 서버에서는 이 URI를 파싱하여 사용자가 지금 로그인을 해달라는 명령을 내렸구나라는것을 판단 할 수 있는 것이다. 이것은 URL이라고 표현하지 않고 URI라고 표현한다.

요즘 대부분은 URI와 URL을 구분하지 않고 혼용하는 경우가 많긴 하다. 하지만 약간은 다른 개념이다.

URN이라는것은 그럼 무엇인가?

자원을 이름을 통해서 식별하겠다는것이다.

내가 지금 어떤 A.jpeg 파일을 찾고 싶다. 근데 이것이 A서버에 있을때는 http://www.server1.com/A.jpeg에서 찾아야 하고,

B서버에 있을때는 http://www.server2.com/A.jpeg에서 찾아야 한다.

그렇기 때문에 사용자가 이 파일이 있는 위치를 알아야 그 파일을 달라고 서버에 요청을 할 수 있는데, 이것이 번거롭다는것이다. 그래서 사용자가 알고있는 정보인 A.jpeg만을 통해서 이 파일을 가져올것이고, 이 파일이 실제 어느 서버에 위치하는지는 신경쓰지 않겠다는 것이다. 

쉽게말하면, 어떤 클라이언트가 "A.jpeg 이 파일 알아서 찾아서 나한테 가져와" 라고 명령을 내리는것과 같다.

그럼 이 파일에 대한 위치가 저장되어 있는 어떤 장치에서 이 파일의 실제 위치에 찾아가 그 파일을 가져온뒤 이 클라이언트에게 전달해준다.

이런방식을 구현하기 위해 생긴것이 URN인데, 지금 현재 상황에서는 많이 사용되지 않고 있다고 한다. 그 이유는, 그 파일에 대한 위치를 저장할 어떤 장치가 필요한데 이것이 많이 널리 퍼져있지 않기 때문이라고 한다.( 웹사이트 주소를 IP주소로 변환해주는 DNS와 같은 역할을 하는 어떤 장치)

한번더 정리하면 URI는 URL과 URN을 포함하는 큰 개념이다.