멋진 URI는 변하지 않는다 (1998)

좋은 URI는 사이트 개편, 담당자 교체, 파일 이동, 구현 기술 변경에도 유지돼야 하며, 처음부터 장기간 존속하도록 설계해야 함 URI를 파일시스템이나 CGI 경로와 분리된 추상 공간으로 다루고 현재 파일 위치와 매핑하면, 내부 구조를 바꾸면서도 기존 링크를 보존할 수 있음 URI에는 작성자, 주제 분류, 문서 상태, 접근 권한, 확장자, 소프트웨어 방식, 디스크 이름처럼 바뀔 정보를 넣지 않아야 하며, 문서 생성일은 변하지 않는 유용한 구성 요소임 온라인 하이퍼텍스트는 독자의 지식 구조와 접근 환경을 고려해 구성하고, 문서별 맥락·상태·작성 책임을 밝히며 기기 독립적 HTML과 의미 있는 링크 텍스트를 사용해야 함 끊어진 링크는 사용자의 작업을 방해하고 서버 운영자에 대한 신뢰를 떨어뜨리므로, URI 안정성과 문서 테스트·접근성·유지보수를 웹 게시의 장기적 책임으로 다뤄야 함 변하지 않는 URI 설계 URI 자체가 변하는 것이 아니라 사람과 조직이 URI를 변경함 도메인 소유자는 파산이나 서버 유지 불능 같은 경우를 제외하면 이름과 그 아래의 URI 공간을 계속 관리할 수 있음 웹사이트 개편을 이유로 이전 URI를 폐기한다면 다음 개편에도 견디지 못할 주소를 다시 만들 가능성이 있음 오래됐거나 공개 범위가 불분명한 문서를 통째로 내리는 대신, 문서마다 배포 범위·생성일·만료일 같은 메타데이터를 보존해야 함 파일 이동이나 담당자 변경은 URI를 바꿀 이유가 아님 Apache 같은 서버는 URI와 실제 파일시스템 위치 사이를 유연하게 매핑할 수 있음 URI를 잘 정돈된 추상 공간으로 두고 현재 저장 구조를 서버 설정으로 연결해야 함 담당자 이름이 URI에 들어가면 소유권 이관 때 주소가 흔들림 cgi-bin, .pl 같은 문자열은 현재 구현 방식을 노출하므로 스크립트나 서버 기술을 바꿀 때 URI까지 변경하게 만듦 NSF 문서 사례에서는 조회용 CGI 주소보다 /pubs/1998/nsf9814/nsf9814.htm처럼 기록의 성격과 연도를 드러내는 주소가 장기 보존에 더 적합함 URN이 영속성을 대신 해결해 준다는 생각은 잘못됨 조직이 지속 가능한 URN을 만들 수 있다면 같은 식별자를 HTTP URI에도 사용할 수 있음 HTTP가 링크를 불안정하게 만드는 것이 아니라 조직의 관리 방식이 안정성을 결정함 영속 URI를 뒷받침하는 도구 이상적인 서버는 영속 URI를 빠르게 조회해 현재 파일을 반환하고, 파일 안의...