NOTE

URL은 “리소스에 접근하는데 필요한 정보”를 “하나의 인터페이스로 나타내는 방법”이다.

키워드#

URL, URL 컴포넌트

메모 및 핵심 요점#

• URL은 어떤 프로토콜에서 리소스에 접근하기 위한 정보를 표준화된 인터페이스로 나타내기 위해 고안되었다. 즉, URL은 리소스를 일관된 방식으로 칭하는 방법이다. 표준화된 인터페이스를 사용하게 되면서 하나의 인터페이스, 즉 하나의 형식(URL 형식)을 통해 다양한 프로토콜에 대하여 리소스에 접근할 수 있게 되었다.
• 리소스를 표현하기 위해서 리소스가 **어떻게(어떤 프로토콜을 통해서 이동하는지), 어디에(어떤 서버에 존재하는지), 무엇을(결국 이 리소스가 무엇인지)**의 구성 요소가 필요하며, 이는 URL의 스킴, 호스트 서버, 리소스 경로 의 구성요소로 나타내어진다.
  • 🌧️ 결국 URL은 해당 리소스를 찾아오기 위해서, 각 프로토콜들이 요구하는 정보를 기술한다. 따라서 URL은 리소스를 위한 기본적인 요소 (어떻게, 어디에, 무엇을)와 프로토콜이 필요로하는 선택적인 정보(아이디, 비밀번호, 파라미터, 쿼리 등)으로 구성되어있다고 생각할 수 있다.
• URL의 구성 요소 중 파라미터는 프로토콜이 요구하는 추가 정보를 기술한다. 이는 ; 로 구분하여 사용한다.
• URL의 구성 요소 중 **질의(쿼리)**는 애플리케이션(DB)에서 요청받을 리소스의 범위를 좁히기 위하여 사용한다. 이는 ? 뒤에 기술되며, & 로 구분하여 사용한다.
• URL의 구성 요소 중 프래그먼트는 전체 리소스 중 일부를 나타내며, 서버에서는 html 의 리소스를 전체적으로 받을 수 밖에 없기 때문에 클라이언트에서만 사용된다.
  • 🌧️ 보통 Table of Content 와 같은 부분에서, 클릭했을 시 해당 section 으로 이동되는데 이 때 사용하는 것이 프래그먼트이다. 즉, 어떤 부분을 클릭하면 해당 부분을 가리키는 프래그먼트를 포함하는 URL로 이동하는 것과 같다.
• 상대 URL의 경우, HTML 을 작성할 때 사용이 가능하다. 브라우저는 HTML을 해석할 때, 이 상대 URL을 절대 URL로 변환하는 과정을 수행한다.
  • 절대 URL을 변환하기 위하여 base URL이 필요한데, 이는 html 태그를 통하여 리소스에서 제공하거나, 해당 리소스의 절대 URL을 그대로 상속받아서 사용할 수 있다.
  • 변환하는 과정은 상대 URL을 통하여 URL의 완전한 구성 요소를 만드는 과정. 따라서 상대 URL에 URL의 구성 요소인 스킴, 호스트 서버, 리소스 경로, 파라미터, 쿼리 등의 값을 채워넣는 과정이라고 생각할 수 있다.
  • 이 값을 채워넣는 방법은 상대 URL에 명시되어있는 경우에는 그 값을 그대로 사용하고, 명시되지 않는 경우에는 base URL에서 상속받는 형식이다.
  • 🌧️ 이렇게 상대 URL 에서 절대 URL 로 변환하는 과정은 URL을 왼쪽에서 오른쪽으로 복원시키는 과정이라고 생각할 수 있다. 일반적인 URL의 구성을 생각해보면 스킴/호스트이름 비밀번호@호스트 서버 주소/리소스주소;파라미터?쿼리#프래그먼트 의 순서인데, 상대 URL에서 정보를 추가하는 과정이 이 URL 컴포넌트 순서대로 일어난다.
• URL의 설계에서 중요하게 생각하는 요소는 어떤 프로토콜을 사용하더라도, 전송하는 내용이 안전하게 전송될 수 있는 것이다. 이 안전하게 전송되는 것은 유실되는 정보가 없음을 뜻하며, 이를 실현하기 위하여 일부 문자 규칙과 이스케이프 문자를 사용한다.
• URL은 특정 시점에 해당 리소스의 위치를 나타내는 것이므로, 위치가 변경되었을 때 해당 리소스를 찾지 못할 수 있다는 단점이 있어서, URN이 고안되고 있다. URN은 리소스에 대한 identifier 로, 리소스의 위치를 사용하는 것이 아니라 리소스의 이름을 사용하는 것인데, PURL을 통하여 URI를 URN으로 사용할 수 있다.
  • URN을 사용하는 경우, URN을 입력하면 서버와 클라이언트 사이에 리소스 리졸버와 같은 중개 서버를 두고, 이 리졸버를 통하여 리소스의 현재 위치를 받아 리소스에 접근한다.

인용#

도시의 리소스를 분류하기 위해서 모든 것이 그만의 표준화된 이름을 가지고 있다. (중략) 모두가 이렇게 각기 다른 이름들에 대한 작명 표준에 동의하기 때문에, 도시에 있는 소중한 리소스를 모두 쉽게 공유할수 있다. (27p)

URL을 사용하면 리소스를 일관된 방식으로 지칭할 수 있다. 대부분의 URL은 동일하게 ‘스킴://서버위치/경로’ 구조로 이루어져 있다. 따라서 인터넷상의 모든 리소스를 가리키고 가져오기 위해, 그리고 모든 사람이 같은 방식으로 이름을 써서 리소스를 찾을 수 있도록 단일 방식의 작명 규칙을 가진 것이다. (29p)

URL을 사용하면 이런 애플리케이션들에서 하나의 인터페이스를 통해 일관된 방식으로 많은 리소스에 접근할 수 있다. (30p)

URL은 당신과 브라우저에게 정보 찾는데 필요한 모든 것을 제공하며, 당신이 원하는 리소스가 어디에 위치하고 어떻게 가져오는지 정의한다. (30p)

사실 URL은 주소이지 실제 이름은 아니다. 이는 URL이 특정 시점에 어떤 것이 위치한 곳을 알려준다는 것을 뜻한다. URL은 리소스를 찾는데 필요한 포트와 서버 이름을 제공한다. 이런 스킴의 단점은 리소스가 옮겨지면 URL을 더 이상 사용할 수 없다는 것이다. 그리고 그 시점에 기존 URL이 가리키고 있던 객체를 찾을 방법이 없어진다. (46p)