저자: Tim Berners-Lee 경, URI, URL, HTTP, HTML 및 월드 와이드 웹의 발명가이자 현재 W3C의 수장입니다. 1998년에 작성된 기사

"멋진" 것으로 간주되는 URI는 무엇입니까?
변하지 않는 것.
URI는 어떻게 변경되나요?
URI는 변경되지 않습니다. 사람들이 URI를 변경합니다.

이론적으로는 사람들이 URI를 변경하거나 지원 문서를 중단할 이유가 없지만 실제로는 수백만 개가 있습니다.

이론적으로 도메인 네임스페이스의 명목 소유자는 실제로 도메인 네임스페이스를 소유하므로 그 안에 있는 모든 URI를 소유합니다. 파산 외에 도메인 이름 소유자가 이름을 유지하는 것을 방해하는 것은 없습니다. 그리고 이론적으로 도메인 이름 아래의 URI 공간은 전적으로 귀하가 제어할 수 있으므로 원하는 대로 안정적으로 만들 수 있습니다. 문서가 인터넷에서 사라지는 유일한 이유는 도메인 이름을 소유한 회사가 폐업했거나 더 이상 서버를 계속 운영할 여력이 없기 때문입니다. 그렇다면 세상에는 왜 이렇게 누락된 고리가 많은 걸까요? 이 중 일부는 단순히 사전 고려가 부족하기 때문입니다. 다음과 같은 몇 가지 이유를 듣게 될 수 있습니다.

우리는 더 나은 사이트를 만들기 위해 사이트를 재구성했습니다.

정말 이전 URI가 더 이상 작동하지 않는다고 생각하시나요? 그렇다면 당신은 그들을 매우 잘못 선택한 것입니다. 다음 재설계를 위해 새 것을 유지하는 것을 고려해보세요.

우리는 오래된 것, 기밀인 것, 여전히 관련 있는 것 등을 추적할 수 없을 정도로 많은 정보를 가지고 있으므로, 우리는 그것을 모두 끄는 것이 최선이라고 생각했습니다.

나는 단지 공감할 수 있습니다. W3C는 보관 자료를 공개하기 전에 기밀 유지를 위해 신중하게 조사해야 하는 기간을 거쳤습니다. 결정은 미리 생각해야 합니다. 각 문서에 허용 가능한 독자층, 작성 날짜 및 이상적으로는 만료 날짜를 기록했는지 확인하십시오. 이 메타데이터를 저장하세요.

글쎄, 우리는 파일을 이동해야 한다는 것을 발견했습니다...

이것은 가장 한심한 변명 중 하나입니다. 많은 사람들은 웹 서버를 통해 개체의 URI와 파일 시스템의 실제 위치 간의 관계를 제어할 수 있다는 사실을 모릅니다. URI 공간을 완벽하게 구성된 추상 공간으로 생각하세요. 그런 다음 그것을 실현하기 위해 실제로 사용하는 현실에 대한 매핑을 만드십시오. 그런 다음 이를 웹 서버에 보고합니다. 서버 조각을 직접 작성하여 올바르게 만들 수도 있습니다.

John은 더 이상 이 파일을 유지하지 않지만 Jane은 이제 유지합니다.

URI에 John의 이름이 있었나요? 아니, 그 파일이 그의 디렉토리에만 있었나요? 글쎄요.

이전에는 이를 위해 CGI 스크립트를 사용했지만 이제는 바이너리 프로그램을 사용합니다.

스크립트에 의해 생성된 페이지가 "cgibin" 또는 "cgi" 영역에 위치해야 한다는 미친 생각이 있습니다. 이는 웹 서버를 실행하는 방법의 메커니즘을 노출합니다. 메커니즘을 변경하면(콘텐츠를 저장하는 동안에도) 죄송합니다. 모든 URI가 변경됩니다.

NSF(National Science Foundation)를 예로 들어 보겠습니다.

NSF 온라인 문서

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

문서 보기를 시작하는 첫 번째 페이지는 몇 년 후에도 동일하게 유지되지 않을 것입니다. cgi-bin, oldbrowse и pl - 이 모든 것은 우리가 지금 어떻게 하고 있는지에 대한 약간의 정보를 제공합니다. 페이지를 사용하여 문서를 검색하는 경우 첫 번째 결과는 마찬가지로 나쁩니다.

암호학과 부호화 이론에 관한 실무그룹 보고서

http://www.nsf.gov/cgi-bin/getpub?nsf9814

문서 색인 페이지의 경우 HTML 문서 자체가 훨씬 좋아 보이지만 다음과 같습니다.

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

여기서 pubs/1998 헤더는 향후 보관 서비스에 이전 1998 문서 분류 체계가 적용되고 있다는 좋은 단서를 제공합니다. 2098년에는 문서 번호가 다르게 보일 수 있지만 이 URI는 여전히 유효하며 NSF나 아카이브를 유지 관리하는 다른 조직을 방해하지 않을 것이라고 생각합니다.

저는 URL이 지속적일 필요는 없다고 생각했습니다. URN이 있었기 때문이죠.

이것은 아마도 URN 논쟁의 최악의 부작용 중 하나일 것입니다. 어떤 사람들은 보다 영구적인 네임스페이스에 대한 연구 때문에 "URN이 모든 것을 해결할 것"이기 때문에 매달린 링크에 대해 부주의할 수도 있다고 생각합니다. 당신이 이런 사람들 중 하나라면 실망시켜 드리겠습니다.

내가 본 대부분의 URN 구성표는 기관 식별자 다음에 날짜와 선택한 문자열 또는 선택한 문자열만 나오는 것처럼 보입니다. 이는 HTTP URI와 매우 유사합니다. 즉, 조직에서 수명이 긴 URN을 생성할 수 있다고 생각한다면 지금 이를 HTTP URI에 사용하여 증명하십시오. HTTP 자체에는 URI를 불안정하게 만드는 것이 없습니다. 귀하의 조직만 가능합니다. 문서 URN을 현재 파일 이름에 매핑하는 데이터베이스를 만들고 웹 서버가 이를 사용하여 실제로 파일을 검색하도록 합니다.

이 지점에 이르렀고 일부 소프트웨어를 개발할 시간, 돈, 연결이 없다면 다음과 같은 변명을 할 수 있습니다.

우리는 원했지만 적절한 도구가 없었습니다.

하지만 이에 대해서는 공감할 수 있습니다. 완전히 동의 해. 당신이 해야 할 일은 웹 서버가 즉시 영구 URI를 구문 분석하고 현재 미친 파일 시스템에 저장된 파일을 반환하도록 강제하는 것입니다. 모든 URI를 검사로 파일에 저장하고 데이터베이스를 항상 최신 상태로 유지하려고 합니다. 동일한 문서의 여러 버전과 번역 간의 관계를 유지하고, 파일이 우발적인 오류로 인해 손상되지 않도록 독립적인 체크섬 기록을 유지하려고 합니다. 그리고 웹 서버에는 이러한 기능이 기본적으로 제공되지 않습니다. 새 문서를 만들 때 편집자는 URI를 지정하도록 요청합니다.

URI를 변경하지 않고도 URI 공간에서 소유권, 문서 액세스, 아카이브 수준 보안 등을 변경할 수 있어야 합니다.

너무 나쁘다. 하지만 상황을 바로잡겠습니다. W3C에서는 버전을 추적하는 Jigedit(Jigsaw 편집 서버) 기능을 사용하고 문서 생성 스크립트를 실험합니다. 도구, 서버, 클라이언트를 개발한다면 이 문제에 주목하세요!

이 변명은 다음 페이지를 포함하여 많은 W3C 페이지에도 적용됩니다. 내가 하는 대로가 아니라 내가 말하는 대로 하십시오.

내가 왜 관심을 가져야 합니까?

서버에서 URI를 변경하면 누가 이전 URI에 대한 링크를 갖게 될지 완전히 알 수 없습니다. 이는 일반 웹 페이지의 링크일 수 있습니다. 페이지를 북마크에 추가하세요. URI는 친구에게 보낸 편지의 여백에 휘갈겨 쓴 것일 수도 있습니다.

누군가 링크를 따라가다가 링크가 끊어지면 일반적으로 서버 소유자에 대한 신뢰를 잃습니다. 그는 또한 자신의 목표를 달성하지 못하여 감정적으로나 육체적으로 좌절감을 느낍니다.

많은 사람들이 항상 끊어진 링크에 대해 불평하고 있으며 피해가 명백하기를 바랍니다. 해당 문서가 사라진 서버 관리자의 명예훼손도 당연하기를 바랍니다.

그래서 내가 무엇을해야하니? URI 디자인

2년, 20년, 200년 뒤에 사용할 수 있는 URI를 할당하는 것은 웹마스터의 몫이다. 이를 위해서는 사려 깊음, 조직 및 결단력이 필요합니다.

URI의 정보가 변경되면 URI도 변경됩니다. 어떻게 디자인하느냐가 매우 중요합니다. (뭐, URI 디자인? URI를 디자인해야 합니까? 네, 생각해 보아야 합니다.) 디자인은 기본적으로 URI에 어떤 정보도 남기지 않는 것을 의미합니다.

문서가 생성된 날짜, 즉 URI가 발행된 날짜는 절대 변하지 않습니다. 이는 새 시스템을 사용하는 쿼리와 이전 시스템을 사용하는 쿼리를 구분하는 데 매우 유용합니다. 이것은 URI로 시작하기에 좋은 곳입니다. 문서에 날짜가 기록되어 있으면 문서가 미래에 관련이 있을지라도 이는 좋은 시작입니다.

유일한 예외는 예를 들어 전체 조직 또는 조직의 상당 부분에 대해 의도적으로 "최신" 버전인 페이지입니다.

http://www.pathfinder.com/money/moneydaily/latest/

머니 매거진의 머니데일리 최신 칼럼입니다. 이 URI에 날짜가 필요하지 않은 주된 이유는 로그보다 오래 지속되는 URI를 저장할 이유가 없기 때문입니다. 머니가 사라지면 머니데일리의 개념도 사라지게 됩니다. 콘텐츠에 연결하려면 아카이브에서 별도로 콘텐츠에 연결해야 합니다.

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(좋아 보입니다. "돈"이 pathfinder.com 전체에서 동일한 의미를 가질 것이라고 가정합니다. 중복된 "98"과 불필요한 ".html"이 있지만 그렇지 않으면 강력한 URI처럼 보입니다.

무엇을 남겨둘까

모두! 생성 날짜 외에도 URI에 정보를 입력하면 어떤 식으로든 문제가 발생합니다.

• 저자 이름. 새 버전이 출시되면 저작권이 변경될 수 있습니다. 사람들은 조직을 떠나 다른 사람에게 물건을 전달합니다.
• 제목. 매우 어렵습니다. 처음에는 항상 좋아 보이지만 놀라울 정도로 빨리 변합니다. 이에 대해서는 아래에서 더 자세히 이야기하겠습니다.
• 지위. "최신" 및 "멋진" 디렉터리는 물론 "오래된", "초안" 등과 같은 디렉터리가 모든 파일 시스템에 나타납니다. 문서 변경 상태 - 그렇지 않으면 초안을 작성할 필요가 없습니다. 최신 버전의 문서에는 상태에 관계없이 영구 식별자가 필요합니다. 이름에서 상태를 유지하십시오.
• 접속하다. W3C에서는 사이트를 직원, 회원, 대중을 위한 섹션으로 나누었습니다. 듣기에는 좋지만 문서는 직원의 팀 아이디어로 시작하여 구성원과 논의되고 대중에게 알려지게 됩니다. 더 폭넓은 논의를 위해 문서를 열 때마다 해당 문서에 대한 이전 링크가 모두 깨진다면 정말 안타까운 일이 될 것입니다! 이제 간단한 날짜 코드로 넘어갑니다.
• 파일 확장자. 매우 흔한 일입니다. "cgi", 심지어 ".html"도 앞으로는 변경될 예정입니다. 20년 후에는 이 페이지에 HTML을 사용하지 않을 수도 있지만, 오늘의 링크는 여전히 작동할 것입니다. W3C 사이트의 정식 링크는 확장명(어떻게 된거야).
• 소프트웨어 메커니즘. URI에서 "cgi", "exec" 및 "우리가 사용 중인 소프트웨어를 살펴보세요"라고 외치는 기타 용어를 찾으세요. Perl CGI 스크립트를 작성하는 데 평생을 보내고 싶은 사람이 있습니까? 아니요? 그런 다음 .pl 확장자를 제거합니다. 이를 수행하는 방법에 대한 서버 매뉴얼을 읽으십시오.
• 디스크 이름. 어서 해봐요! 그러나 나는 이것을 본 적이 있다.

우리 사이트의 가장 좋은 예는 다음과 같습니다.

http://www.w3.org/1998/12/01/chairs

... W3C 의장 회의록을 보고합니다.

주제별 주제 및 분류

이 위험은 가장 피하기 어려운 위험 중 하나이기 때문에 이에 대해 더 자세히 설명하겠습니다. 일반적으로 문서가 수행하는 작업을 기준으로 문서를 분류하면 주제가 URI로 표시됩니다. 하지만 이 분류는 시간이 지나면서 바뀔 것입니다. 지역 이름이 변경됩니다. W3C에서는 MarkUP을 Markup으로 변경한 다음 섹션의 실제 내용을 반영하기 위해 HTML로 변경하고 싶었습니다. 또한 평면 네임스페이스가 있는 경우도 많습니다. 100년 후에는 어떤 것도 재사용하고 싶지 않을 것이라고 확신하시나요? 예를 들어 짧은 인생에서 우리는 이미 "역사"와 "스타일 시트"를 재사용하고 싶었습니다.

이는 웹 사이트를 구성하는 매력적인 방법이자 전체 웹을 포함하여 모든 것을 구성하는 정말 매력적인 방법입니다. 이는 중기적으로는 훌륭한 솔루션이지만 장기적으로 보면 심각한 단점이 있습니다.

그 이유 중 하나는 의미의 철학에 있습니다. 언어의 모든 용어는 클러스터링의 잠재적인 대상이며, 사람마다 그것이 의미하는 바가 다를 수 있습니다. 개체 간의 관계는 나무라기보다는 웹에 더 가깝기 때문에 웹에 동의하는 사람이라도 나무에 대한 다른 표현을 선택할 수도 있습니다. 이것은 일반적인 해결책으로서 계층적 분류의 위험성에 대한 나의 (자주 반복되는) 일반적인 관찰입니다.

실제로 URI에서 주제 이름을 사용하면 일종의 분류에 전념하게 됩니다. 아마도 앞으로는 다른 옵션을 선호하게 될 것입니다. 그러면 URI가 위반되기 쉽습니다.

제목 영역을 URI의 일부로 사용하는 이유는 일반적으로 URI 공간의 하위 섹션에 대한 책임이 위임되고 해당 하위 공간을 담당하는 조직 기관(부서, 그룹 등)의 이름이 필요하기 때문입니다. 이는 조직 구조에 대한 URI 바인딩입니다. 일반적으로 추가(왼쪽) URI가 날짜로 보호되는 경우에만 안전합니다. 1998/pics는 서버에 "1998년에 우리가 지금 사진이라고 부르는 작업을 수행한 작업"이 아니라 "1998년에 사진을 사용하여 의미한 작업"을 의미할 수 있습니다.

도메인 이름을 잊지 마세요

이는 URI의 경로뿐만 아니라 서버 이름에도 적용된다는 점을 기억하십시오. 다양한 용도로 별도의 서버가 있는 경우, 수많은 링크를 파괴하지 않고서는 이 분할을 변경할 수 없다는 점을 기억하십시오. "오늘날 우리가 사용하는 소프트웨어를 살펴보는" 전형적인 실수로는 도메인 이름 "cgi.pathfinder.com", "secure", "lists.w3.org" 등이 있습니다. 이는 서버 관리를 더 쉽게 만들기 위해 설계되었습니다. 도메인이 회사의 부서, 문서 상태, 액세스 수준 또는 보안 수준을 나타내는지 여부에 관계없이 여러 문서 유형에 대해 두 개 이상의 도메인 이름을 사용하기 전에는 매우 주의해야 합니다. 리디렉션 및 프록시를 사용하여 표시되는 단일 웹 서버 내에 여러 웹 서버를 숨길 수 있다는 점을 기억하십시오.

아, 도메인 이름도 생각해 보세요. 제품 라인을 변경하고 비누 생산을 중단한 후에는 비누.com으로 불리고 싶지 않을 것입니다(현재 비누.com 소유자에게는 죄송합니다).

결론

2년, 20년, 200년, 심지어 2000년 동안 URI를 보존하는 것은 보기만큼 쉽지 않습니다. 그러나 인터넷 전체에서 웹마스터들은 미래에 이 작업을 정말로 어렵게 만드는 결정을 내리고 있습니다. 종종 이는 현재 최고의 사이트를 제공하는 도구를 사용하고 모든 것이 변경되면 링크에 어떤 일이 일어날지 아무도 평가하지 않았기 때문입니다. 그러나 여기서 중요한 점은 아주 많은 것들이 변경될 수 있으며 URI는 동일하게 유지될 수 있고 유지되어야 한다는 것입니다. 이는 어떻게 만드는지 생각할 때만 가능합니다.

참조 :

• 같은 주제에 대한 Jakob Nielsen의 장광설

추가

파일 확장자를 제거하는 방법...

...현재 파일 기반 웹 서버의 URI에서?

예를 들어 Apache를 사용하는 경우 콘텐츠를 협상하도록 구성할 수 있습니다. 파일 확장자(예: .png)를 파일(예: mydog.png), 그러나 그것 없이도 웹 리소스에 연결할 수 있습니다. 그런 다음 Apache는 해당 이름과 확장자를 가진 모든 파일의 디렉터리를 확인하고 집합에서 가장 적합한 파일(예: GIF 및 PNG)을 선택할 수 있습니다. 그리고 서로 다른 디렉터리에 서로 다른 유형의 파일을 넣을 필요가 없습니다. 실제로 그렇게 하면 콘텐츠 일치가 작동하지 않습니다.

• 콘텐츠 협상을 위한 서버 설정
• 항상 확장자 없이 URI에 연결

확장 기능이 포함된 링크는 계속 작동하지만 서버가 현재와 미래에 사용 가능한 최상의 형식을 선택하지 못하게 됩니다.

(사실은, mydog, mydog.png и mydog.gif — 유효한 웹 리소스, mydog 범용 콘텐츠 유형 리소스입니다. mydog.png и mydog.gif — 특정 콘텐츠 유형의 리소스).

물론, 자신만의 웹 서버를 작성하는 경우 데이터베이스가 무한정 증가할 수 있다는 점에 유의하더라도 데이터베이스를 사용하여 영구 식별자를 현재 형식에 바인딩하는 것이 좋습니다.

수치심의 판 - 이야기 1: 채널 7

1999년에 눈으로 인해 학교가 폐쇄된 상황을 추적했습니다. http://www.whdh.com/stormforce/closings.shtml. TV 화면 하단에 정보가 나타날 때까지 기다리지 마세요! 내 홈 페이지에서 링크했습니다. 2000년 첫 큰 눈보라가 닥쳤고 나는 페이지를 확인했다. 거기에 쓰여 있습니다 :,

- 현재.
현재 문을 닫은 곳은 없습니다. 기상특보가 있을 경우 반납해 주시기 바랍니다.

이렇게 강한 폭풍이 아닐 수 없습니다. 날짜가 빠진게 웃긴다. 하지만 사이트의 메인 페이지로 이동하면 "Closed Schools(폐쇄된 학교)"라는 큰 버튼이 표시되어 해당 페이지로 연결됩니다. http://www.whdh.com/stormforce/ 문을 닫은 학교의 긴 목록이 있습니다.

어쩌면 목록을 가져오기 위한 시스템을 변경했을 수도 있지만 URI를 변경할 필요는 없었습니다.

수치심의 판 - 이야기 2: Microsoft Netmeeting

인터넷에 대한 의존도가 높아지면서 제조업체의 웹사이트 링크를 애플리케이션에 내장할 수 있다는 기발한 아이디어가 나왔습니다. 이것은 많이 사용되고 남용되었지만 URL은 변경할 수 없습니다. 얼마 전 도움말/웹의 Microsoft/무료 항목 메뉴에 있는 Microsoft Netmeeting 2/뭔가 클라이언트의 링크를 시도했는데 404 오류가 발생했습니다. 서버에서 응답을 찾을 수 없습니다. 어쩌면 이미 해결됐을지도...

© 1998 팀 BL

역사적 참고 사항: 이 글이 쓰여졌던 20세기 후반에 "쿨"은 특히 젊은이들 사이에서 유행, 품질 또는 적절성을 나타내는 승인의 별명이었습니다. 급하게 URI 경로는 유용성이나 내구성보다는 "멋짐"을 위해 선택되는 경우가 많습니다. 이 게시물은 멋진 것을 추구하는 에너지의 방향을 바꾸려는 시도입니다.

출처 : habr.com