이 페이지는 11ty라는 정적 사이트 생성기를 이용해 제작되었다. 그런데 이를 공부하던 중 URL에 붙은 trailing slash, 즉 URL 마지막에 붙은 /을 붙일지에 대한 이야기가 있었다. 또 거기서 파생되어 좋은 URI를 짓는 법에 대한 글이 있어 이들을 읽으며 메모하였다.
Cool URIs don't change
이론적으로만 따졌을 때, 도메인을 소유한 회사나 개인의 파산을 제외하면 자원의 식별자인 URI가 바뀔 일은 없다. 하지만 실질적으로 URI의 변경은 엄청나게 많이 일어난다. 따라서 인터넷 상에는 깨진 링크가 엄청나게 많다. 인터넷을 많이 하는 사람이라면 한번쯤 깨진 링크를 본 적이 있을 것이다.
이 글에서는 URI를 일반적으로 바꾸는 이유, 그 이유들이 타당하지 않다는 주장 그리고 좋은 URI를 설계하기 위한 원칙을 제시한다.
- 웹사이트 구조를 바꿨을 경우
기존의 URI들도 동작할 수 있도록 새로운 구조를 설계하라.
- 자료가 너무 많아서 더 이상 자료 분류 등을 추적할 수 없었기에 모든 걸 지우기로 했다.
W3C도 그런 일을 겪었다고 한다. 그룹의 문서들을 공개 아카이브로 돌리기 전에 기밀로 분류된 문서들을 걸러내야 했다. 이런 문제를 막기 위한 방법은 "사전 대비"(forethought)라고 한다. 문서 생성 시에 아예 허용 가능한 배포범위, 생성날짜, 만료날짜 등의 메타데이터를 만들고 추적하라.
- 파일을 옮겨야 했다.
Apache와 같은 서버들은 URI와 실제 파일 시스템 상의 위치간에 유연한 매핑을 설정할 수 있다. 따라서 파일의 이동과 상관 없이 URI를 유지 가능.
- 원래는 cgi 스크립트를 썼는데 이제 바이너리 프로그램을 써서 이를 관리한다.
이 문서는 1998년 팀 버너스 리가 인터넷의 태동기에 쓴 문서다. 이 당시에는 CGI(common gateway interface)라는 걸로 웹 문서를 만드는 것도 일반적이었다. 그리고 이때는 cgi 스크립트로 만든 문서를 /cgibin 같은 경로 하에 두기도 했나 보다.
하지만 여기서는 "문서가 어떤 방식으로 만들어졌는지"를 URI에 포함시키지 말라고 경고한다. 요즘으로 따지면 index.php 가 붙은 경로를 생각할 수 있겠다. 지금은 이 문서가 php로 만들어졌지만 미래에도 그러리란 보장은 없잖아?
이외에도 URI를 제대로 설계하기 위한 자원 부족 등 URI가 바뀌는 여러가지 이유들을 열거한다. 근데 그래서 좋은 URI는 어떻게 설계하는데?
URI가 바뀌는 이유는 바뀔 수 있는 정보가 URI에 포함되어 있기 때문이다. 따라서 URI 설계란 필요없는/변할 수 있는 정보들을 쳐내는 과정이다.
그럼 URI에 포함할 바뀌지 않을 정보로 적절한 건 문서의 생성 날짜다. 이건 새로운 시스템에 대한 요청/기존 시스템에 대한 요청의 분리에도 유용하다(특정 날짜 이후의 URI에는 새로운 시스템을 적용하도록 하면 되므로)
이렇게 URI에 날짜를 포함시키는 것의 예외는 의도적으로 "최신"을 나타내기 위한 URI다. 예를 들어 잡지의 가장 최신호를 보여주는 페이지 /latest 등.
생성일을 제외한 이외의 것들은 모두 바뀔 수 있기 때문에 이걸 URI에 넣는 건 문제의 여지를 만든다고 한다.
- 작성자: 조직 개편 등에 따라 당연히 바뀔 수 있음
- 주제: 생각보다 쉽게 바뀜. 이후에 다시 설명
- 상태: old, draft 같은 것. 문서의 상태는 당연히 바뀐다. 초안에서 정식이 되기도 하고 그런 거지
- 접근 권한: 팀 문서, 개별 문서, 공용 문서. 당연히 이런 접근 권한은 바뀜
- 파일 확장자, 소프트웨어 형식: 지금은
.html이나 Perl cgi(실제로 한 시대를 풍미했음)로 제공되는 페이지가 나중에는 다른 방식으로 서비스될 수 있다. - 디스크명: 제발 쓰지마세요
따라서 이런 식으로 설계된 W3C 의장단 회의록 URI는 이렇다.
http://www.w3.org/1998/12/01/chairs
- 문서의 주제는 왜 바뀌는가?
앞서 문서 주제가 생각보다 쉽게 바뀐다고 했다. 이건 문서의 분류가 업무 분류 체계를 반영하는 게 일반적이기 때문이다. 업무 분류 체계는 시간이 지나면서 바뀐다. 분야의 명칭도 바뀐다. 예를 들어 "MarkUp"을 "HTML" 분류로 이름을 바꾸는 경우가 W3C에서 있었다고 한다.
또한 분류 이름은 겹칠 때가 많다. 대규모 웹사이트라면 'History'라는 분류가 여러 개 있을 수도 있다! 이런 주제별 분류는 중기적으론 좋지만 장기적으로는 문제 소지가 있다고 한디.
주제를 URI에 포함시키는 건, 특정 분류 체계에 URI를 종속시킨다. 나중에 다른 체계를 사용하게 되면? URI가 바뀌고 링크가 깨진다.
따라서 이런 경우 날짜 정보를 URI에 포함시켰을 때 제한적으로 사용한다. 또한 URI 해석을 날짜 기반으로 해야 한다. 1998/pics는 pics에 대한 1998년의 문서가 아니라, 1998년에 우리가 pics라고 불렀던 것에 대한 문서라고 보는 것이다. 상위 -> 하위 순서로 해석.
- 도메인 이름도 주의
바뀔 수 있는 정보를 도메인명에 포함시키는 것에 대해서도 주의하라. 가령 cgi.example.com 같은 거. cgi를 계속 쓸 거라고 장담할 수 있는가? 나중에 js.example.com으로 바뀌게 되면 기존 페이지 링크는 전부 깨질 테다.
리디렉션이나 프록시를 통해 하나의 도메인 뒤에 여러 웹 서버를 둘 수 있다는 걸 기억하라.
세상은 변하지만 URI는 변하지 않을 수 있고 또 그래야만 한다. 그걸 위해서는 애초에 설계할 때부터 신중히 고민하고 변하지 않을 정보로 URI를 구성해야 한다.
- 파일 확장자를 URI에서 제거하는 법
아파치 등에서 지원하는 콘텐츠 협상(content negotiation) 사용
지속 가능한 URI를 설계하자
URL as UI
닐슨노먼그룹의 제이콥 닐슨이 URL에 대해 쓴 URL as UI에 있는 좋은 URL의 요구사항
- 기억하기 쉽고 스펠링이 쉽고 입력하기 쉬움
- 짧음
- 사이트 구조를 시각화함
- URL 끝을 잘라내서 상위 구조로 이동 가능함(원문은 hackable)
- 변하지 않음(persistent)
원칙적으로는 URL은 기계에서 사용하는 주소체계일 뿐이므로 사용자가 알 필요는 없다. 그러나 어쨌든 사용자는 페이지에 접근하는 과정에서 URL에 자주 노출되므로 이걸 고려하면 위의 요구사항에 더하여 URL을 이렇게 지어야 함
- 회사 이름/주요 브랜드를 나타냄
- 줄바꿈 없이 한 줄에 표시되도록 하여 메일에서도 링크가 깨지지 않게 하려면 78자 이하
- 대소문자 섞어서 사용하지 않기(사용자들은 대소문자 구분해서 기억 못함)
- 오타 없음
Trailing slash에 대하여
여러 형식과 각 플랫폼에서 어떻게 대처하는지에 대해