URI란?
URI(identifier) = URL(Location), URN(Name)가 합쳐진 것.
리소스를 통일적일 방식으로 식별하는 ID로 URI를 사용하면 웹상에 존재하는 모든 리소스를 같은 방식으로 접속할 수 있다.
URI 구문
간단한 URI
- URI Scheme: 사용하는 프로토콜, 웹은 HTTP, 그 뒤는 '://' 표시로 구분된다.
- 호스트명: DNS에서 이름을 해석할 수 있는 도메인명이나 IP 어드레스로 반드시 인터넷에서 일의성을 가지고 있다.
- 패스: 호스트 내에서의 리소스가 위치한 경로로 계층화를 나타낸다.
유일한 호스트명 + 패스 구조로 전 세계의 다른 리소스와 절대 중복되지 않도록 되어있다.
복잡한 URI
- + 간단한 URI
- 사용자 정보: URI Scheme 다음에 등장하고 리소스에 액세스하기 위한 사용자 아이디와 비밀번호로 구성된다. (아이디:패스워드)
- 포트 번호: 호스트에 액세스 할 때 프로토콜이 사용할 TCP의 포트번호, 호스트 정보는 호스트명 + 포트번호로 구성되어 있다. 포트 번호를 적지 않으면 프로토콜의 디폴트 포트번호로 지정이 되는데 HTTP의 디폴트 포트번호는 80이다. 호스트명 다음에 :로 구분되어 붙여진다.
- 쿼리 파라미터: & 뒤에 붙여지며 name=value형식으로 여러 개는 ;로 구분되어 붙여진다. 검색 키워드를 전달할 때 등 클라이언트에서 동적으로 URI를 생성할 때 사용한다.
- URI 프레그먼트: & 뒤에 붙여지며 해당 리소스의 특정 부분을 가리킬 때 사용된다.
절대 URI와 상대 URI
URI는 /로 루트와 디렉토리명을 구분하여 계층화를 표현한다.
절대 URI
스키마와 호스트명(루트)에서의 전체 경로가 모두 명시된 URI
상대 URI
스키마와 호스트명을 생략하고 그 후부터의 URI의 경로로 표현한 URI.
Base URI
보통 상대 URI의 시작 경로를 알 수 없기 때문에 기점이 되는 URI를 지정한 것이 Base URI이다.
하지만 변경되거나 정확하게 알지 못하는 경우도 있으니 되도록이면 절대 URI를 사용하자.
2가지의 URI 부여 방식
- 리소스의 URI를 base URI로 지정 : 상대 URI가 출현하는 리소스의 URI를 Base URI로 부여하는 방식이다. 직관적이고 이해하기 쉽지만 클라이언트가 리소스의 base URI를 알고 있어야 한다.
- 명시적으로 지정하는 법: HTML이나 XMI에서 Base URI를 명시적으로 지정해주는 방식이다. HTML 헤더에 base 태그로 경로를 설정해준다.
URI에서 사용하는 문자들
아스키코드로 변환이 가능한 문자들로만 경로를 구성할 수 있다.
( 알파벳, 숫자, 기호: -.~:@!$&'() )
URI 인코딩: 그 이외의 문자들은 보통 % 인코딩을 통해 변환을 해야 한다. 보통 %가 앞에 붙는 인코딩으로 UTP-8 문자들을 인코딩할 수 있다. 단 아스키코드 % 는 % 인코딩에서 사용하고 있기 때문에 %25라고 표기해야 한다.
여러 문자들을 인코딩할 수 있지만 그 폼에서 제공하고 있는 웹페이지의 문자 인코딩을 사용하지만 프록시에서 문자 인코딩을 변환하는 경우나 근본 웹페이지의 문자 인코딩 범위가 맞지 않는 경우 오류가 생긴다. 대부분의 웹사이트들은 UTF-8으로 % 인코딩을 사용하니 UTF-8로 지정하는 것이 무난하다.
URI의 길이 제한
URI의 길이 제한은 스펙상으로는 없지만 구현상(IE에서는 몇 자리까지만 허용)에서는 있다.
URI 구현 시 주의할 점
상대 URI를 해석하기 위해서는 번거로운 처리가 필요하니 되도록이면 절대 URI를 사용하자.
가능 한 한 UTP-8 인코딩을 하자.
Cool한 URI란?
- 프로그래밍 언어에 의존적인 확장자와 경로를 포함하지 않는다: 특정 언어에 의존하는 문자열과 경로를 포함시키면 다른 언어로 변경하거나 경로가 변경하자마자 URI가 존재하지 않아 진다.
- 메서드명을 포함하지 않아야 한다: 메서드가 바뀌면 또 URI 가 존재하지 않아 진다.
- 세션 ID를 포함하지 않아야 한다: 로그인할 때마다 세션 ID가 바뀌기 때문에 URI가 바뀐다.
- URI는 해당 리소스를 표현하는 명사이다: 어떤 리소스를 취득할 것인지에 대한 것은 URI가 아닌 이미 메서드에서 결정된다. 리소스(명사)를 메서드(동사)한다라는 관계임으로 그거에 맞게 명사형으로 표시해야 한다.
개발자와 사용자 모두에게 기억하기 쉽고 사용하기 쉽게 만들어져야 Cool URI이다.
URI 변경은 최대한 하면 안 되지만 꼭 해야 하는 경우라면 redirect로 옮겨주어야 한다. 301 (영구적으로 옮겨짐) 응답 메시지를 이용해 리다이렉트 해주면 된다.
매트릭스 URI
URI 설계를 할 때 사용하는 기술로 확장자 표현(언어)을 지정하는 방법이다.
콘텐츠 네고시에이션
사용자에 맞는 언어로 리소스를 표현해주는 것이다.(한국어를 사용하는 유저에게는 한국어를 영어를 사용하는 유저에게는 영어로)
문서에 .ko, .uk 등의 확장자 붙여 해당하는 언어로 표현된 리소스를 제공한다. 맞는 언어를 사용하기 위해서는 브라우저의 성정을 따로 변경해주어야 한다.
마찬가지로 Accept 헤더에 미디어 타입을 지정하거나 Accept-Charset 헤더를 이용해 문자 인코딩을 지정할 수 있다.
매트릭스 URI
모든 정보들을 계층적으로 관리할 수 없기 때문에 사용하는 방식으로 파라미터를 세미콜론(;)으로 구분해서 여러 파라미터의 조합으로 리소스를 표현해준다. 파라미터 순서 중요도가 있는 경우는 , 로만 연결해 지정해줄 수 있다.
예) 위도 경도의 표현은 계층적으로 관리할 수 없다.
URI 불투명성
클라이언트에서 URI를 추측해서 접근하더라도 반드시 리소스가 있으리라는 법은 없다. 클라이언트는 어디까지나 서버가 제공하는 URI를 그대로 사용한다.
서버에서 설계한 URI를 클라이언트에서는 몰라야 한다.클라이언트에서 URI를 구축할 경우 서버에서 URI구조를 변경하는 순간 시스템이 동작하지 않는 문제(밀결합)가 생긴다.
이렇게 URI를 클라이언트 쪽에서 구성하거나 확장자로 리소스의 내용을 추단 할 수 없는 특성을 'URI는 클라이언트에 있어 불투명하다'라고 한다.
클라이언트 애플리케이션을 만들 때는 불투명성을 의식해서 구현해야 한다.
한 줄로 정리하는 URI란? URI는 리소스 이름이다, 수명이 길다, 브라우저 어드레스 란에 표시된다.