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 등 이다.

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〉, 《네이버 지식백과》