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 클래스이다.

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