URI

통합 자원 식별자(Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소이다.

개요

통합 자원 식별자(Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소이다. URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다. 통합 자원 식별자(URI가)는 문자열 문자를 명확하게 식별하고 특정 자원을 균일성 있게 보장한다. 그래서 모든 URI는 사전정의 된 구문 규칙을 따르고 별도로 정의 된 계층적 이름 지정 체계를 통해 확장성 을 유지 한다. http:// 이러한 식별은 특정 프로토콜을 사용하여 네트워크를 일반적으로 월드 와이드 웹을 통해 리소스 표현과 상호 작용할 수있게 한다. 구체적인 구문관련 프로토콜을 지정하는 체계는 각 URI를 정의한다. 가장 일반적인 URI 형식은 URL(Uniform Resource Locator )이며, 비공식적 웹 주소 라고한다. URN( Uniform Resource Name )은 특정 네임 스페이스에서 리소스를 식별하기위한 메커니즘을 제공하여 URL을 보완하도록 디자인 된 경우이외에만 사용되며 일반적으로 거의 사용되지 않는다.

역사

URI와 URL은 역사를 함께 공유한다. 1994년 팀 버너스 리가 하이퍼텍스트를 제안하면서 하이퍼링크의 대상이 되는 자원을 대표하는 짧은 문자열로 URL의 개념을 암묵적으로 도입하였다. 당시 사람들은 이를 "하이퍼텍스트 이름"또는 "문서 이름"으로 불렀다. 향후 3년 반 동안 HTML, HTTP 및 웹 브라우저에 대한 월드 와이드 웹의 핵심 기술이 개발됨에 따라 리소스 주소를 제공하는 문자열과 단순히 리소스라는 이름의 문자열을 구분해야했다. URL과 URN 정의에 대한 토론에서 두 용어로 구현 된 개념은 단지 자원 식별의 기본적이고 지나치게 중요한 개념이라는 측면에 불과하다는 것이 분명해졌다. 1994 년 6월, IETF 는 URL과 URN의 존재를 인정한 최초의 의견 요청인 Berners-Lee의 RFC 1630을 출판했습니다. 가장 중요한 것은 Universal Resource Identifiers(예 : 정확한 구문과 의미가 체계에 따라 달라지는 URL 유사 문자열)에 대한 공식 구문을 정의한 것이다. 또한 RFC는 당시에 사용중인 URL 체계의 구문을 요약하려고 시도했다. 일반 URI와 절대 URI 참조 문법은 RFC 2396에 처음 정의되었다. 1998년 8월 출판되었으며,RFC 3986로 완성되어, 2005년 1월 출판되었다. URI에 대 한 사양은 RFC 2396, RFC 2732, RFC 3986 및 RFC 3987을 게시 하 여는 Task Force IETF (Internet Engineering)에 나와 있다.

특징

URI에는 인트라넷 또는 인터넷에서 애플리케이션에 사용할 수 있는 리소스의 compact표현이다. URI는 속성 및 메서드 구문 분석, 비교 및 결합을 포함 하는 URI를 처리 하기 위한 클래스를 정의 한다. URI클래스 속성은 읽기 전용 이며 수정할 수 있는 개체를 만들어서 사용 한다. 그것이 UriBuilder 클래스이다.

URL

URL(Uniform Resource Locator, 문화어: 파일식별자, 유일자원지시기)은 네트워크 상에서 자원이 어디 있는지를 알려주기 위한 규약이다. 즉, 컴퓨터 네트워크와 검색 메커니즘에서의 위치를 지정하는, 웹 리소스에 대한 참조이다. 흔히 웹 사이트 주소로 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타낼 수 있다. 그 주소에 접속하려면 해당 URL에 맞는 프로토콜을 알아야 하고, 그와 동일한 프로토콜로 접속해야 한다. FTP 프로토콜인 경우에는 FTP 클라이언트를 이용해야 하고, HTTP인 경우에는 웹 브라우저를 이용해야 한다. 텔넷의 경우에는 텔넷 프로그램을 이용해서 접속해야 한다. 우리가 원하는 정보를 인터넷에서 찾기 위해서는 그 정보가 어디에 위치해 있는지를 아는 것이 중요하다. 이때 정보가 들어있는 웹페이지의 위치를 나타내는 주소가 있다. 이것이 바로 URL이다. URL은 기본적으로 '통신 규칙://인터넷 호스트 주소/경로 이름'으로 이루어진다. 포털 사이트 홈페이지 http;//www.naver.com를 예로 들어 보면 http는 인터넷에서 서로 다른 컴퓨터끼리 데이터를 주고 받기 위한 규칙, 즉 통신 규약이다. 이 통신 규약 뒤에는 콜론(:)을 붙이고 도메인 네임이나 IP 주소를 더 써야 하는 경우에는 슬래시 두 개(//)를 덧붙여준다. www.naver.com은 인터넷 사이트의 도메인 네임으로, 우리가 원하는 정보가 naver라는 이름을 가진 서버(또는 컴퓨터) 안에 들어있기 때문에 그곳에 접속하겠다는 의미이다. 그리고 naver에 속한 여러 웹페이지에 들어가게 되면 도메인 이름 뒤에 슬래시 한 개(/)가 더 붙게 된다. 뒤이어 파일 경로와 사용하는 컴퓨터의 자원 이름이 나오는 것이다. 위에서 웹사이트를 대표적인 예로 들었지만 웹사이트 이외에도 네트워크를 이용하는 곳이라면 어디서든 URL을 이용하여 필요한 정보나 자원이 어디 있는지 나타낼 수 있다. 이처럼 URL은 인터넷 도메인 이름이나 IP 주소, 이메일, 파일 전송 등 컴퓨터 네트워크 정보를 이용하는 모든 것에 적용할 수 있는 것이다.

URL의 형태와 특징

• 프로토콜

URL의 맨 앞에 있는 것은 프로토콜(protocol)이라고 하는데, 이는 컴퓨터 네트워크 상에서 서로 다른 컴퓨터끼리 데이터를 주고 받기 위한 통신 규약 중 하나다. 위의 예에서 쓰인 ‘http'는 인터넷에서 웹 브라우저로 문서나 파일을 표시하기 위한 공통 규약이므로, 일단 이 URL은 일반적인 인터넷 서핑을 위한 것임을 알 수 있다. 그리고 프로토콜 뒤에는 콜론( : )을 적으며 도메인 이름이나 IP 주소로 이어지는 경우 콜론( : )뒤에 슬래시 2개( // )를 덧붙여준다.

• 정보 자원을 가진 컴퓨터의 위치

그리고 프로토콜 뒤에 표시된 것은 사용자가 접속하고자 하는 네트워크(혹은 인터넷) 상의 컴퓨터 위치이다. 위의 예에서 static.naver.com이 표기 되어 있는데 이는 네이버 사이트의 도메인 이름이므로 사용자가 원하는 네트워크 정보 자원이 네이버의 서버 컴퓨터 안에 있음을 알 수 있다.

• 파일 디렉토리

그리고 컴퓨터 이름 뒤에 표시된 www/u/2010/0611/는 디렉토리(파일 경로, 폴더)를 뜻하는데, 위의 경우 네이버 서버 컴퓨터의 하드디스크에 ‘www’라는 이름의 디렉토리가 있으며 이 안에는 ‘u/2010/0611/’로 이어지는 하위 디렉토리가 포함되어 있다는 것을 알 수 있다. 파일 디렉토리는 생략할 수 있다.이 때는 컴퓨터 관리자가 정한 기본 디렉토리를 뜻하게 된다.

• 정보 자원 이름

그리고 마지막에 표시되는 것은 사용자가 얻고자 하는 정보 자원(흔히 파일)의 이름이다. 위의 예에는 ‘nmms_215646753.gif’가 표기되어 있는데, 이는 확장자(컴퓨터 파일명 뒤에 붙는 구분 기호)를 보면 알 수 있듯 GIF 그림 파일의 일종이다. 따라서 위 사용자는 네이버의 서버 컴퓨터 안에 저장된 nmms_215646753.gif 라는 이름의 그림 파일을 보기 위해 위와 같은 URL을 입력했음을 알 수 있다. 역시 편의상 생략하는 경우가 많다. 생략되면 컴퓨터가 관리자가 정한 기본 정보 자원 이름을 뜻하게 되는데, 보통은 index.html, default.html 등 이다.

URN

URI(Uniform Resource Identifiers)의 한 형태로서 URI는 URN(Uniform Resource Names)과 URL(Uniform Resource Locators)이 합쳐진 형태.URL은 인터넷에 존재하는 수많은 정보자원의 위치를 정확하고 편리하게 표현하기 위한 방법으로 일반적인 주소를 말한다. 자료에 접근할 프로토콜과 접속할 호스트 이름, 그 자료 파일이 존재하는 경로, 그리고 파일 이름으로 구성된다. 이에 반해 URN은 URL과는 달리 정보의 실제위치에 관계없이 해당 정보에 접근할 수 있는 것으로, 물리적으로 정보가 바뀌더라도 해당 정보에 대한 URN은 일정하게 유지된다. URL 방식의 인터넷 자원 식별체계는 위치에 대응되는 콘텐츠가 없어지거나 더 이상 이용할 수 없게 되는 경우에는 검색 수단으로서의 기능을 상실하는 등 정확한 식별기능이 떨어져 콘텐츠 유통에 맞지 않다는 지적이 있다. 이를 해결하기 위해 URN(uniform resource names)을 이용하는 방법이 세계적인 추세이며, 디지털콘텐츠 유통에 관한 국제표준화기구인 MPEG-21과 TV-애니타임 등에서 권장하고 있다. URN은 콘텐츠의 위치, 프로토콜, 호스트 등과는 상관없이 각각의 콘텐츠에 이름을 부여한 것으로, 개별 콘텐츠에 식별자를 부여하게 되면, 콘텐츠의 위치, 프로토콜, 호스트와 관계없이 콘텐츠의 위치를 파악할 수 있으며, 관련 정보도 함께 담을 수 있다는 장점이 있다. IETF(Internet Engineering Task Force) 규격에 의하면 URN은 유일성ㆍ영속성ㆍ확장성ㆍ융통성ㆍ규모성 등을 제공할 수 있어야 한다. 즉, URL은 어떤 특정 서버에 있는 웹 문서를 가리키는 반면, URN은 웹 문서의 물리적인 위치와 상관없이 웹 문서 자체를 지시한다. 따라서 웹사이트에 있는 어떤 웹 문서가 다른 웹 서버로 이동하거나 주소가 바뀌더라도 URN은 여전히 그 문서를 가리키고 있기 때문에 사용자는 그 문서에 대한 URN을 갖고 있으면 그 문서가 어떤 웹 서버로 이동되어 있더라도 그 문서를 찾을 수 있는 것이다.

RFC

RFC(Request for Comments) 문서는 비평을 기다리는 문서라는 의미로, 컴퓨터 네트워크 공학 등에서 인터넷 기술에 적용 가능한 새로운 연구, 혁신, 기법 등을 아우르는 메모를 나타낸다. 인터넷 협회(Internet Society)에서 기술자 및 컴퓨터 과학자들은 RFC 메모의 형태로 생각을 출판하게 되며, 이러한 출판의 목적은 자신의 새로운 생각 및 정보에 대해 전문가 비평을 바라는 것, 혹은 그러한 생각을 단순히 전달하는 것이다. 때로는 공학적인 유머를 위해서이기도 하다(만우절 RFC를 참조하기 바란다). 인터넷국제표준화기구(IETF)는 일부 RFC를 인터넷 표준으로 받아들이기도 한다. RFC 편집자는 매 RFC 문서에 일련 번호를 부여한다. 일단 일련 번호를 부여 받고 출판되면, RFC는 절대 폐지되거나 수정되지 않는다. 만약 어떤 RFC 문서가 수정이 필요하다면, 저자는 수정된 문서를 다른 RFC 문서로 다시 출판해야 한다. 그러므로, 일부 RFC는 이전 버전의 RFC를 개선한 문서이며, 이전 버전의 RFC를 무효화하기도 한다. 이러한 덮어쓰는 방식을 통해, 번호 순으로 나열된 일련의 RFC는 인터넷 표준의 역사를 나타내기도 한다. URI에 대 한 사양은 RFC 2396, RFC 2732, RFC 3986 및 RFC 3987을 게시 하 여는 Task Force IETF (Internet Engineering)에 나와 있다.

REST서비스

REST는 Representational state transfer의 약자로, 월드와이드웹과 같은 분산 하이퍼미디어 시스템에서 운영되는 소프트웨어 아키텍처스타일이다. 2000년에 Roy Fielding에 의해 처음 용어가 사용되었는데, HTTP/1.0, 1.1 스펙 작성에 참여했었고 아파치 HTTP 서버 프로젝트의 공동설립자이기도 하다. REST는 HTTP/1.1 스펙과 동시에 만들어졌는데, HTTP 프로토콜을 정확히 의도에 맞게 활용하여 디자인하게 유도하고 있기 때문에 디자인 기준이 명확해지며, 의미적인 범용성을 지니므로 중간 계층의 컴포넌트들이 서비스를 최적화하는 데 도움이 된다. REST의 기본 원칙을 성실히 지킨 서비스 디자인은 “RESTful 하다.”라고 흔히 표현한다. 무엇보다 이렇게 잘 디자인된 API는 서비스가 여러 플랫폼을 지원해야 할 때, 혹은 API로서 공개되어야 할 때, 설명을 간결하게 해주며 여러 가지 문제 상황을 지혜롭게 해결하기 때문에 (버전, 포맷/언어 선택과 같은) REST는 최근의 모바일, 웹 서비스 아키텍처로서 아주 중요한 역할을 하고 있다. REST에서 가장 중요하며 기본적인 규칙은 아래 두 가지이다.

• URI는 정보의 자원을 표현해야 한다.
• 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.

요청 필터링(Request Filtering)과 URL Rewrite기술

요청 필터링은 IIS7에서 기본적으로 제공하는 보안 기능이다. 이전에는 URLScan 이라는 녀석의 기능과 비슷하기도 하다. 간단히 이녀석이 수행하는 기능은 IIS의 내장된 보안 기능으로 특정 URL이 들어올 경우 필터링, 특정 파일 확장자(Extension)을 요청할 경우 필터링, ASP.NET의 App_code와 같은 폴더에 대한 접근 필터링, HTTP 헤더의 길이 제한, HTTP의 특정한 verb에 대한 필터링 등이 가능하다. 아울러, 요청 필터링은 이러한 보안 필터링 기능을 웹사이트단위 또는 웹서버 전체에 대해서 적용 가능하다. 요청 필터링과 URL Rewrite의 비슷한점은 두가지 기능 모두 URL이나 HTTP Request에 대한 보안 기능을 적용 가능하다는 점에서는 유사하다. 하지만 아래와 같은 차이점이 있다. 요청필터링은 순수한 보안 목적으로 제작되었지만 URL Rewrite는 범용적인 URL 처리를 위한 목적으로 제작되었으며, URL Rewrite가 제공하는 보안 기능은 여러가지 기능들 중의 일부이다. 성능 측면에서는 두가지 기술 모두 영향을 줄 정도로 부하가 높지는 않다. 하지만, URL Rewrite의 경우 정규표현식을 이용하기 때문에 요청 필터링 보다는 약간 더 높은 시스템 리소스를 이용하게 된다. 요청 핕터링은 문자열에 대한 추출 작업만을 진행해 비교하기 때문에 시스템 리소스를 상대적으로 덜 사용하게 된다. URL Rewrite와 요청 핕터링은 각각의 목적에 맞는 보안 기능들이 있으며 필요할 경우 두 기능을 조합해서 이용도 가능하다.

참고자료

• 〈통합 자원 식별자〉, 《위키백과》
• 〈균일 한 자원 식별자〉, 《위키피디아》
• 김대우,〈요청 필터링과 URL Rewrite〉, 《마이크로소프트 블로그》, 2009-10-14
• 김재석,〈REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁〉, 《Spoqa》, 2012-02-27
• 〈URL〉, 《위키백과》
• 소프트웨어 용어사전,〈URL〉, 《네이버 지식백과》
• 용어로 보는 IT,〈URL〉, 《네이버 지식백과》
• 매일경제,〈URN〉, 《네이버 지식백과》
• 시사상식사전,〈URN〉, 《네이버 지식백과》
• 〈RFC〉, 《위키백과》