Resource
Resource는 모든 Contents의 원천이며, 정적 리소스와 동적 리소스로 나눠서 생각할 수 있다.
- 정적 리소스 : HTML, IMAGE, ...
- 동적 리소스 : 요청 정보에 따라 다른 컨텐츠를 생성
따라서, 모든 종류의 Contents Source는 Resource가 될 수 있다.
URI
URI는 통합 자원 식별자(Uniform Resource Identifier)로, 인터넷 상에 모든 Resource를 고유하게 식별하고 위치를 지정하는 식별자이다. URI는 세부적으로 URL, URN 두 종류의 식별자로 구분된다.
URL
URL은 통합 자원 지시자(Uniform Resource Locator)로, Resource의 구체적인 위치 정보를 나타낸다. URL를 통해 Resource가 어디에 있으며 어떻게 접근할 수 있는 지를 쉽게 알 수 있다. 또한 URL은 '스킴://서버위치/리소스경로' 구조로 이루어지며, 모든 사람이 같은 방식으로 리소스를 탐색할 수 있도록 일관된 방식을 제공한다.
URL 문자 집합
역사적으로 이전의 많은 애플리케이션은 US-ASCII 문자 집합을 사용해왔다. US-ASCII는 영문자를 중심으로 설계되었고, 7bit 만을 사용하며 많은 제어 문자를 표현할 수 없었다. 따라서 URL 설계자들은 URL에 이스케이프 문자열을 쓸 수 있게끔 설계하였다.
이스케이프 문자열은 US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 한다. 인코딩은 안전하지 않은 문자를 '%' 문자로 시작하여 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 '이스케이프' 문자로 바꾼다.
| 문자 | ASCII 코드 | URL |
|---|---|---|
| ~ | 126(0X7E) | http://www.example.com/ %7E hello |
| % | 137(0X25) | http://www.example.com/100 %25 hello |
%, : 같은 몇 가지 문자는 URL 내에서 특별한 의미로 예약되어 있다. URL에서 예약된 문자들을 본래의 목적과 다르게 사용하려면, 그 전에 반드시 인코딩을 해야한다. 아래는 예약된 주요 문자들이다.
%, /, ., .., #, ?, ;, :, @, &, =, $, +, ~
안전하지 않은 모든 문자를 인코딩하기만 하면, 다른 애플리케이션으로 부터 특별한 의미를 가지는 문자를 받았을 때 혼동할 걱정없이, 애플리케이션 간에 URL 원형을 유지하여 공유할 수 있다.
URL 구조
사용자는 하나의 Resource를 서로 다른 Scheme으로 접근할 수 있으며, URL 형식은 스킴에 따라 달라진다. 일반적인 URL의 전체적인 구조는 아래와 같다.
<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
| 컴포넌트 | 설명 |
|---|---|
| 스킴 | 프로토콜 정보 기재한다. |
| 사용자 이름 | FTP 같은 스킴은 리소스에 접근하기 위해서는 사용자 이름이 필요하다. |
| 비밀번호 | 사용자 이름에 대한 비밀번호이다. |
| 호스트 | 리소스를 제공하는 서버의 도메인 이나 IP 주소이다. |
| 포트 | 서버가 해당 스킴으로 접근 가능하도록 열어 놓은 포트번호 |
| 경로 | 서버 내 리소스의 위치 정보를 나타낸다. |
| 파라미터 | 특정 스킴에서 입력 파라미터를 기술하는 용도(key/value 구조) |
| 질의 | 질의 컴포넌트의 공통 포맷은 없으며, 애플리케이션에 파라미터를 전달하는 용도 |
| 프래그먼트 | 리소스의 일부분을 가리키는 이름으로, 클라이언트에서만 사용하는 용도 |
스킴 (Scheme)
스킴은 리소스 접근 방식을 알려주는 중요한 정보이고, 사용자가 어떤 프로토콜 이용해서 리소스를 요청해야 하는 지를 나타낸다. 각 스킴에 대한 구체적인 정보는 // 로 구분되어 이후에 나타나는 규격을 가지고 있다. 스킴 정보에 따라 <사용자 이름>:<비밀번호>@, :<비밀번호>, :<포트>, /<경로>; 정보는 필요없을 수도 있다. 또한, 스킴은 대소문자를 구분하지 않는다.
호스트 & 포트
호스트 컴포넌트는 리소스를 제공하는 호스트 정보로 Domain Name, Ip Address로 식별 가능하다. Domain Name은 영문자 또는 숫자로 구성되며 '-' 특수 문자를 포함할 수 있다. 포트 컴포넌트는 호스트가 제공하는 네트워크 포트로, 각 스킴마다 디폴트 포트 번호를 가지고 있다. 호스트와 포트는 ':' 문자로 구분한다.
사용자 이름 & 비밀번호
리소스를 특정 사용자에게만 제공하고 싶은 경우가 있을 것이다. 이러한 경우에 호스트는 리소스에 접근하기 전에 사용자 이름과 비밀번호를 요구할 수 있다. 사용자 이름의 디폴트는 'anonymous' 이고, 비밀번호는 브라우저마다 다른 디폴트를 제공한다. 사용자 이름과 비밀번호를 명시해야 한다면 '@'로 다른 컴포넌트와 구분하며, 이름과 비밀번호는 ':' 문자로 분리한다.
경로
경로 컴포넌트는 호스트 내부에서의 리소스 위치 정보를 나타낸다. 경로 컴포넌트는 '/' 특수문자를 기준으로 경로 조각으로 나뉜다. 각 경로 조각은 자신만의 파라미터 컴포넌트를 가질 수 있다.
파라미터
많은 스킴은 리소스를 탐색하기 위해 더 많은 정보를 요구한다. 예를 들어 보자.
만약 바이너리, 텍스트 두 개의 포맷을 지원하는 FTP 프로토콜이 있다고 가정하자. 만약 사용자가 바이너리 이미지 요청에서 프로토콜 파라미터(type, 전송 모드 설정)를 명시하지 않았다면, FTP 프로토콜은 어떠한 포맷을 지원해야 하는지 알지 못하기 때문에 바이너리를 텍스트 형식으로 전송할 수도 있다.
위와 경우와 같이, 정확한 요청을 하기 위해서는 파라미터 컴포넌트(key/value)가 필요하다. 파라미터 컴포넌트는 리소스에 접근하기 위한 추가 정보 역할을 하는 것이다. 파라미터 컴포넌트는 ';' 특수문자로 구분된다.
ftp://www.example.com/image.png;type=binary
질의 문자열
질의 문자열 컴포넌트는 리소스의 형식 범위를 좁히기 위해서 질의하는 데 사용한다. 질의 컴포넌트는 다른 컴포넌트와 '?' 특수문자로 구분하고, 내부적으로는 key/value 구조로 각각은 '&' 특수문자로 나뉜다. 아래 예시와 같이, country가 korea인 리소스가 존재하는 지 질의하는데 사용할 수 있다.
프래그먼트
프래그먼트는 클라이언트에 해당되는 규격이다. HTML 같은 리소스는 이상적으로 내부의 특정 절을 가리킬 수 있어야 한다. URL은 리소스 내의 특정 조각을 가리킬 수 있도록 프래그먼트 조각을 제공한다. 아래 예시와 같이, 서버에서 받아온 lionking 전체 리소스 중에서 story 부분을 가리킬 수 있다.
상대 URL
URL은 상대 URL과 절대 URL로 나뉜다. 절대 URL은 리소스 접근하기 위해 모든 정보가 필요하지만, 상대 URL은 짧게 표기하는 방식으로 기저(Base) 라 하는 다른 URL을 사용한다.
만약 아래와 같은 HTML이 있다고 가정하자.
hello.html 내부에서는 다른 URL을 참조할 수 있을 것이다.
<html>
// ...
<body>
// ...
<a href = './other.html'>링크</a>
// ...
</body>
</html><a> 태그가 참조하는 URL이 미완성인 것처럼 보이나, 이는 해당 문서의 URL을 기준으로 상대경로로 해석할 수 있다. 이렇듯, 상대 URL을 사용하면 스킴, 호스트 등의 컴포넌트 정보를 현재 리소스의 URL을 기준으로 추측할 수 있는 것이다. 그럼 기저 URL은 무엇일까?
기저 URL은 상대 URL의 기준이고 여러가지 채택 방식이 존재한다.
- 리소스에서 명시적으로 제공 : HTML 문서에서는 태그로 기저 URL을 설정할 수 있다.
- 리소스에 포함된 경우 : 기저 URL를 명시하지 않은 경우에는 해당 리소스의 URL을 기저 URL로 설정할 수 있다.
상대 URL은 결국 내부적으로 각각의 컴포넌트 조각으로 나누고, 이를 절대 URL로 변환하는 알고리즘이 필요로 한다.
URN
URN은 유니폼 리소스 이름(Uniform Resource Name)으로, Resource의 위치와 상관없이 식별 가능한 고유한 이름 역할을 한다. 이론 상으로 URN은 위치와 독립적이며 리소스 위치가 변경되더라도 문제없이 동작한다. 즉, Resource 위치와 상관없이 이름만으로 식별할 수 있다는 개념이다. URN은 인프라 지원이 미비하며, 통상적으로 URI와 URL을 같은 의미로 사용한다.
참고
