해시넷
URI
URI(유알아이)는 "Uniform Resource Identifier"의 약자로서, 인터넷에 존재하는 각종 정보들의 유일한 이름이나 위치를 표시하는 식별자이다. URI에는 고유한 위치를 표시하는 URL과 고유한 이름을 표시하는 URN이 있다. URI는 인터넷에 있는 자원을 나타내는 유일한 주소로서, 통합 자원 식별자라고도 한다.
개요[편집]
통합 자원 식별자(Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소이다. URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다.[1] 통합 자원 식별자(URI가)는 문자열 문자를 명확하게 식별하고 특정 자원을 균일성 있게 보장한다. 그래서 모든 URI는 사전정의 된 구문 규칙을 따르고 별도로 정의 된 계층적 이름 지정 체계를 통해 확장성을 유지한다. http:// 이러한 식별은 특정 프로토콜을 사용하여 네트워크를 일반적으로 월드 와이드 웹을 통해 리소스 표현과 상호 작용할 수 있게 한다. 구체적인 구문관련 프로토콜을 지정하는 체계는 각 URI를 정의한다. 가장 일반적인 URI 형식은 URL(Uniform Resource Locator)이며, 비공식적 웹 주소라고한다. URN(Uniform Resource Name)은 특정 네임스페이스에서 리소스를 식별하기 위한 메커니즘을 제공하여 URL을 보완하도록 디자인된 경우 이외에만 사용되며 일반적으로 거의 사용되지 않는다.[2]
역사[편집]
URI와 URL은 역사를 함께 공유한다. 1994년 팀 버너스-리가 하이퍼텍스트를 제안하면서 하이퍼링크의 대상이 되는 자원을 대표하는 짧은 문자열로 URL의 개념을 암묵적으로 도입하였다. 당시 사람들은 이를 "하이퍼텍스트 이름"또는 "문서 이름"으로 불렀다. 향후 3년 반 동안 HTML, HTTP 및 웹 브라우저에 대한 월드 와이드 웹의 핵심 기술이 개발됨에 따라 리소스 주소를 제공하는 문자열과 단순히 리소스라는 이름의 문자열을 구분해야 했다. URL과 URN 정의에 대한 토론에서 두 용어로 구현된 개념은 단지 자원 식별의 기본적이고 지나치게 중요한 개념이라는 측면에 불과하다는 것이 분명해졌다.
1994년 6월, IETF는 URL과 URN의 존재를 인정한 최초의 의견 요청인 팀 버너스-리(Tim 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)에 나와 있다.[2]
특징[편집]
URI 인터넷 서비스(웹 서비스 등)를 전제로 하여, 인터넷 응용 정보자원(텍스트,비디오,음향,이미지,기타 서비스 등)에 대한 통일적 식별체계를 지칭하는 개념적 용어이다. URI에는 인트라넷 또는 인터넷에서 애플리케이션에 사용할 수 있는 리소스의 compact표현이다. URI는 속성 및 메소드 구문 분석, 비교 및 결합을 포함 하는 URI를 처리 하기 위한 클래스를 정의 한다. URI클래스 속성은 읽기 전용 이며 수정할 수 있는 개체를 만들어서 사용 한다. 그것이 UriBuilder 클래스이다. 단순히 정적인 자원의 위치나 식별을 나타내는 수준에서 점차적으로 동적 자원이나 서비스 결합 등을 고려하였다. 문자체계가 과거 US - ASCII코드에서, 유니코드(Unicode)를 적용하는 국제화된 URI 확장 표준인 IRI(Internationalized Resource Identifier)를 도모하였다.
- URI %인코딩 방식 例) `나` => UTF-8 인코딩 `%EB%82%98` (동양권 문자 3 바이트)[3]
단순하게 말하자면, URI는 규약이고, URL은 규약에 대한 형태라고 생각하면 혼동되지 않을 것이다. 수학적으로 말하자면, URL과 URN은 부분집합이라고 생각할 수 있다.[4]
URL(통합 자원 위치)[편집]
URL(Uniform Resource Locator, 문화어: 파일식별자, 유일자원지시기)은 네트워크 상에서 자원이 어디 있는지를 알려주기 위한 규약이다. 즉, 컴퓨터 네트워크와 검색 메커니즘에서의 위치를 지정하는, 웹 리소스에 대한 참조이다. 흔히 웹 사이트 주소로 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타낼 수 있다. 그 주소에 접속하려면 해당 URL에 맞는 프로토콜을 알아야 하고, 그와 동일한 프로토콜로 접속해야 한다. FTP 프로토콜인 경우에는 FTP 클라이언트를 이용해야 하고, HTTP인 경우에는 웹 브라우저를 이용해야 한다. 텔넷의 경우에는 텔넷 프로그램을 이용해서 접속해야 한다.[5] 우리가 원하는 정보를 인터넷에서 찾기 위해서는 그 정보가 어디에 위치해 있는지를 아는 것이 중요하다. 이때 정보가 들어있는 웹페이지의 위치를 나타내는 주소가 있다. 이것이 바로 URL이다. URL은 기본적으로 '통신 규칙://인터넷 호스트 주소/경로 이름'으로 이루어진다. 포털 사이트 홈페이지 http;//www.naver.com를 예로 들어 보면 http는 인터넷에서 서로 다른 컴퓨터끼리 데이터를 주고 받기 위한 규칙, 즉 통신 규약이다. 이 통신 규약 뒤에는 콜론(:)을 붙이고 도메인 네임이나 IP 주소를 더 써야 하는 경우에는 슬래시 두 개(//)를 덧붙여준다. www.naver.com은 인터넷 사이트의 도메인 네임으로, 우리가 원하는 정보가 naver라는 이름을 가진 서버(또는 컴퓨터) 안에 들어있기 때문에 그곳에 접속하겠다는 의미이다. 그리고 naver에 속한 여러 웹페이지에 들어가게 되면 도메인 이름 뒤에 슬래시 한 개(/)가 더 붙게 된다. 뒤이어 파일 경로와 사용하는 컴퓨터의 자원 이름이 나오는 것이다. 위에서 웹사이트를 대표적인 예로 들었지만 웹사이트 이외에도 네트워크를 이용하는 곳이라면 어디서든 URL을 이용하여 필요한 정보나 자원이 어디 있는지 나타낼 수 있다. 이처럼 URL은 인터넷 도메인 이름이나 IP 주소, 이메일, 파일 전송 등 컴퓨터 네트워크 정보를 이용하는 모든 것에 적용할 수 있는 것이다.[6]
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 등 이다.[7]
URN(통합 자원 이름)[편집]
URI(Uniform Resource Identifiers)의 한 형태로서 URI는 URN(Uniform Resource Names)과 URL(Uniform Resource Locators)이 합쳐진 형태.URL은 인터넷에 존재하는 수많은 정보자원의 위치를 정확하고 편리하게 표현하기 위한 방법으로 일반적인 주소를 말한다. 자료에 접근할 프로토콜과 접속할 호스트 이름, 그 자료 파일이 존재하는 경로, 그리고 파일 이름으로 구성된다. 이에 반해 URN은 URL과는 달리 정보의 실제위치에 관계없이 해당 정보에 접근할 수 있는 것으로, 물리적으로 정보가 바뀌더라도 해당 정보에 대한 URN은 일정하게 유지된다.[8] URL 방식의 인터넷 자원 식별체계는 위치에 대응되는 콘텐츠가 없어지거나 더 이상 이용할 수 없게 되는 경우에는 검색 수단으로서의 기능을 상실하는 등 정확한 식별기능이 떨어져 콘텐츠 유통에 맞지 않다는 지적이 있다. 이를 해결하기 위해 URN(uniform resource names)을 이용하는 방법이 세계적인 추세이며, 디지털콘텐츠 유통에 관한 국제표준화기구인 MPEG-21과 TV-애니타임 등에서 권장하고 있다. URN은 콘텐츠의 위치, 프로토콜, 호스트 등과는 상관없이 각각의 콘텐츠에 이름을 부여한 것으로, 개별 콘텐츠에 식별자를 부여하게 되면, 콘텐츠의 위치, 프로토콜, 호스트와 관계없이 콘텐츠의 위치를 파악할 수 있으며, 관련 정보도 함께 담을 수 있다는 장점이 있다. IETF(Internet Engineering Task Force) 규격에 의하면 URN은 유일성ㆍ영속성ㆍ확장성ㆍ융통성ㆍ규모성 등을 제공할 수 있어야 한다. 즉, URL은 어떤 특정 서버에 있는 웹 문서를 가리키는 반면, URN은 웹 문서의 물리적인 위치와 상관없이 웹 문서 자체를 지시한다. 따라서 웹사이트에 있는 어떤 웹 문서가 다른 웹 서버로 이동하거나 주소가 바뀌더라도 URN은 여전히 그 문서를 가리키고 있기 때문에 사용자는 그 문서에 대한 URN을 갖고 있으면 그 문서가 어떤 웹 서버로 이동되어 있더라도 그 문서를 찾을 수 있는 것이다.[9]
RFC[편집]
RFC(Request for Comments) 문서는 비평을 기다리는 문서라는 의미로, 컴퓨터 네트워크 공학 등에서 인터넷 기술에 적용 가능한 새로운 연구, 혁신, 기법 등을 아우르는 메모를 나타낸다. 인터넷 협회(Internet Society)에서 기술자 및 컴퓨터 과학자들은 RFC 메모의 형태로 생각을 출판하게 되며, 이러한 출판의 목적은 자신의 새로운 생각 및 정보에 대해 전문가 비평을 바라는 것, 혹은 그러한 생각을 단순히 전달하는 것이다. 때로는 공학적인 유머를 위해서이기도 하다. 인터넷국제표준화기구(IETF)는 일부 RFC를 인터넷 표준으로 받아들이기도 한다. RFC 편집자는 매 RFC 문서에 일련 번호를 부여한다. 일단 일련 번호를 부여 받고 출판되면, RFC는 절대 폐지되거나 수정되지 않는다. 만약 어떤 RFC 문서가 수정이 필요하다면, 저자는 수정된 문서를 다른 RFC 문서로 다시 출판해야 한다. 그러므로, 일부 RFC는 이전 버전의 RFC를 개선한 문서이며, 이전 버전의 RFC를 무효화하기도 한다. 이러한 덮어쓰는 방식을 통해, 번호 순으로 나열된 일련의 RFC는 인터넷 표준의 역사를 나타내기도 한다.[10] 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에서 가장 중요하며 기본적인 규칙은 아래 두 가지이다.
요청 필터링(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와 요청 핕터링은 각각의 목적에 맞는 보안 기능들이 있으며 필요할 경우 두 기능을 조합해서 이용도 가능하다.[12]
활용[편집]
URI 구문[편집]
- 구문 => URI스킴: //사용자이름:암호@호스트명:포트번호/경로?쿼리#URI프래그먼트
- `콜론(:)`은 2개를 묶은 쌍(pair)에서 좌우 구분을 위한 구분자 임
- `대시(//)`는 어떤 시작을 알리는 것
- 원칙적으로 URI 길이 제한 없으나, 구현상 2천자 등의 상한선 있음
URI Scheme(스킴)[편집]
접근 프로토콜을 가리킴
- URI 표기에서, URI 시작부터 콜론(:) 직전까지의 표현
- HTTP => http;//www.ktword.co.kr
- FTP => ftp;//file.fileserver.com/entries/01
- 이메일 => mailto;사용자이름@호스트명?Subject=Feedback
- SIP => sip;사용자이름:암호@호스트명;uri-parameters
- 전화 => tel;1234;phone-context=servername.example.com
호스트명(Hostname)[편집]
- 인터넷 상에서 유일한 식별
- 여기서, 호스트명은, FQDN 또는 IP 주소 모두 가능
- 위에서, `www.ktword.co.kr`, `file.fileserver.com`
경로(path)[편집]
위에서, 호스트명 직후에 있는 `/entries/01`[3]
URL의 구조[편집]
스키마[편집]
- 스키마(scheme)는 사용할 프로토콜을 말하며, 리소스에 어떻게 요청, 접근할 것인지를 명시한다.
- 웹에서 주로 HTTP 프로토콜을 사용한다.
- 그 밖에 ftp, mailto(이메일), rtsp(스트리밍)과 같은 프로토콜을 사용할 수도 있다.
사용자 이름과 비밀번호[편집]
- 어떤 서버들은 자신이 가지고 있는 데이터에 접근하기 위해서 사용자의 이름과 비밀번호를 요구한다. ex) ftp;//victolee:12345@호스트/asd.xls
- 만약 웹 서버에서 사용자이름과 비밀번호를 요구하는 URL 스킴을 사용함에도 클라이언트가 이를 명시하지 않고 URL에 접근한다면, 기본값으로 "사용자 이름 : anonumous , 비밀번호는 브라우저에서 제공하는 기본 값"을 따르게 된다.
호스트와 포트[편집]
- 하나의 Host(컴퓨터)에는 여러 개의 Process(프로그램)이 각각의 소켓(socket)을 사용하여 데이터 통신을 하고 있기 때문에, 각각의 소켓을 구분할 필요가 있다.
- 소켓을 구분하는 역할을 하는 것이 포트(port)이다.
- 로컬에서 개발을 했을 때 접근하는 URL은 localhost:8080 일 것이다.
- 이처럼 서버에는 포트에 따라 소켓이 연결되어 있고, 포트 번호에 따라 다른 프로토콜이 사용될 수 있다.
- HTTP 프로토콜에서 포트 번호를 명시하지 않으면, 80번 포트를 기본 값으로 사용한다. ( Well-known port - 링크 ) 예) http;//www.google.com:80
경로[편집]
- 호스트에서 제공하는 자원의 경로를 의미한다. 예) https;//movie.naver.com/movie/running/current.nhn
질의[편집]
- 쿼리스트링(query string)이라고도 한다.
- 클라이언트가 자원을 GET 방식으로 요청할 때, 필요한 데이터를 함께 넘겨줄 목적으로 사용한다.
- 개발할 때 함수를 호출하면 파라미터를 던져주는데, 이와 비슷하다고 보면 된다. 예) http;//localhost:3000/index?id=3&page=1
프래그먼트[편집]
- HTML에는 각각의 요소에 id 속성을 부여할 수 있는데 URL에 프래그먼트를 전달하면 페이지가 해당 id가 있는 곳으로 스크롤이 이동하게 된다.
- 이 글의 URL에 프래그먼트를 추가하면, 가장 마지막으로 이동할 것입니다. 예) http;//victorydntmd.tistory.com/287#bottom[13]
http;//www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
- http:// : http 는 프로토콜(규약)이다. URL의 첫 파트는 브라우저가 어떤 규약을 사용해야 하는 지를 나타낸다. 프로토콜은 컴퓨터 네트워크에서 데이터를 교환하거나 전송하기 위한 방법들의 세트이다. 보통 웹사이트들을 위해, 이것은 HTTP 프로토콜이나 HTTP 프로토콜의 보안 버전이다.
- www.example.com : www.example.com은 도메인 이름이다. 이것은 어떤 웹 서버가 요구되는 것인 지를 가리킨다. 대안으로, 직접 IP address를 사용하는 것도 가능하다. 그러나 덜 편리하기 때문에, 그것은 웹에서 주로 사용되지는 않는다.
- :80 : :80은 포트이다. 이것은 기술적으로 웹서버에서 자원을 접근하기 위해 사용하는 "관문(gate)"을 가리킨다. 만약 웹서버가 자원의 접근 하기 위해 표준 HTTP 포트 (HTTP를 위한 80, HTTPS를 위한 443)를 사용한다면, 포트 번호는 보통 생략한다. 그렇지 않으면 포트 번호는 필수이다.
- /path/to/myfile.html : /path/to/myfile.html 은 웹서버에서 자원에 대한 경로이다. 초기의 웹에서는, 웹서버상에서 물리적 파일 위치를 나타냈다. 요즘에는, 실제 물리적 경로를 나타내지 않고, 웹 서버에서 추상화하여 보여준다.
- ?key1=value1&key2=value2 : ?key1=value1&key2=value2 는 웹서버에 제공하는 추가 파라미터이다. 이 파라미터들은 & 기호로 구분된 키/값으로 짝을 이룬 리스트이다. 웹 서버는 자원을 반환하기 전에 추가적인 작업을 위해 이런 파라미터들을 사용할 수 있다. 각각의 웹서버는 파라미터들을 언급하는 자신의 규칙을 갖고 있다. 그리고, 특정한 웹서버가 파라미터를 다루는지 알기 위한 유일한 방법은 웹서버 소유자에게 묻는 것이다.
- #SomewhereInTheDocument : #SomewhereInTheDocument 는 자원 자체의 다른 부분에 대한 anchor(닻)이다. An anchor 는 일종의 자원 안에서 "bookmark" 이다. 즉, "bookmarked" 지점에 위치된 내용을 보여주기 위해 브라우저에게 방향을 알려준다. 예를 들어, HTML 문서에서 브라우저는 anchor가 정의한 곳의 점을 스크롤할 것이다.[14]
종류[편집]
- 절대(Absolute) URI : 모든 전체 경로를 다 기술한 URI 표현 (길이가 매우 클 수 있음)
- 상대(Relative) URI : 전체 경로 중 기준 URI로부터 상대적 경로 표현
- 기준(Base) URI : 보통, HTML 문서 내 `Head 요소` 안에 `Base 요소`에 표시[3]
IRI[편집]
URI는 오직 아스키(ASCII) 인코딩만 지원하지만, IRI(International Resource Identifier)는 ASCII를 포함하여 모든 문자 규격을 지원하되 주로 UTF-8을 통해 전 세계의 문자셋을 지원한다. 따라서 IRI는 URI의 상위개념이라고 할 수도 있다. 장점으로는 라틴어(A~Z) 알파벳에 익숙하지 않은 사용자가 쉽게 사용할 수 있다. 유니코드를 복제하는 것이 어렵지 않은 사람에게는 URI 시스템의 액세스 가능성을 높일 수 있다. 단점은 IRI와 ASCII URI를 혼합하면 해킹을 훨씬 쉽게 수행하여 다른 사이트에 있는 사람들에게 피싱 공격을 할 수 있다.[15]
각주[편집]
- ↑ 〈통합 자원 식별자〉, 《위키백과》
- ↑ 2.0 2.1 〈균일 한 자원 식별자〉, 《위키피디아》
- ↑ 3.0 3.1 3.2 차재복,〈URI〉, 《정보통신기술용어해설》
- ↑ 마이구미,〈URIvsURLvsURN〉, 《티스토리》,2017-03-25
- ↑ 〈URL〉, 《위키백과》
- ↑ 소프트웨어 용어사전,〈URL〉, 《네이버 지식백과》
- ↑ 용어로 보는 IT,〈URL〉, 《네이버 지식백과》
- ↑ 매일경제,〈URN〉, 《네이버 지식백과》
- ↑ 시사상식사전,〈URN〉, 《네이버 지식백과》
- ↑ 〈RFC〉, 《위키백과》
- ↑ 김재석,〈REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁〉, 《Spoqa》, 2012-02-27
- ↑ 김대우, 〈요청 필터링과 URL Rewrite〉, 《마이크로소프트 블로그》, 2009-10-14
- ↑ victolee,〈[HTTP URI, URL 구조]〉, 《티스토리》
- ↑ 〈What is a URL?〉, 《모질라》
- ↑ "Internationalized Resource Identifier", Wikipedia
참고자료[편집]
- 〈통합 자원 식별자〉, 《위키백과》
- 〈균일 한 자원 식별자〉, 《위키피디아》
- 김대우,〈요청 필터링과 URL Rewrite〉, 《마이크로소프트 블로그》, 2009-10-14
- 김재석,〈REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁〉, 《Spoqa》, 2012-02-27
- 〈URL〉, 《위키백과》
- 소프트웨어 용어사전,〈URL〉, 《네이버 지식백과》
- 용어로 보는 IT,〈URL〉, 《네이버 지식백과》
- 매일경제,〈URN〉, 《네이버 지식백과》
- 시사상식사전,〈URN〉, 《네이버 지식백과》
- 〈RFC〉, 《위키백과》
- 차재복,〈URI〉, 《정보통신기술용어해설》
- 마이구미,〈URIvsURLvsURN〉, 《티스토리》,2017-03-25
- GIFTBOT,〈URL,IRI 차이점〉, 《네이버 블로그》,2016-10-17
- 〈Internationalized Resource Identifier〉, 《위키피디아》
- 〈What is a URL?〉, 《모질라》
- victolee,〈[HTTP URI, URL 구조]〉, 《티스토리》
같이 보기[편집]
