Tác giả: Ngài Tim Berners-Lee, người phát minh ra URI, URL, HTTP, HTML và World Wide Web, đồng thời là người đứng đầu hiện tại của W3C. Bài viết năm 1998

URI nào được coi là "tuyệt vời"?
Một điều không thay đổi.
URI được thay đổi như thế nào?
URI không thay đổi: mọi người thay đổi chúng.

Về lý thuyết, không có lý do gì để mọi người thay đổi URI (hoặc ngừng tài liệu hỗ trợ), nhưng trên thực tế có hàng triệu URI như vậy.

Về lý thuyết, chủ sở hữu danh nghĩa của một không gian tên miền thực sự sở hữu không gian tên miền đó và do đó sở hữu tất cả các URI bên trong nó. Ngoài việc mất khả năng thanh toán, không có gì ngăn cản chủ sở hữu tên miền giữ tên đó. Và về lý thuyết, không gian URI dưới tên miền của bạn hoàn toàn nằm trong tầm kiểm soát của bạn nên bạn có thể làm cho nó ổn định theo ý muốn. Hầu như lý do chính đáng duy nhất khiến một tài liệu biến mất khỏi Internet là công ty sở hữu tên miền đó đã ngừng hoạt động hoặc không còn đủ khả năng để duy trì hoạt động của máy chủ. Vậy thì tại sao trên thế giới lại có nhiều liên kết bị thiếu đến vậy? Một số điều này chỉ đơn giản là sự thiếu suy nghĩ trước. Dưới đây là một số lý do bạn có thể nghe thấy:

Chúng tôi chỉ tổ chức lại trang web để làm cho nó tốt hơn.

Bạn có thực sự nghĩ rằng các URI cũ không thể hoạt động được nữa không? Nếu vậy thì bạn đã chọn họ rất kém. Hãy cân nhắc giữ lại những cái mới cho lần thiết kế lại tiếp theo.

Chúng tôi có quá nhiều thứ đến nỗi chúng tôi không thể theo dõi những gì đã lỗi thời, những gì bí mật và những gì vẫn còn liên quan, vì vậy chúng tôi nghĩ tốt nhất là tắt tất cả những thứ đó đi.

Tôi chỉ có thể thông cảm. W3C đã trải qua giai đoạn chúng tôi phải sàng lọc cẩn thận các tài liệu lưu trữ để đảm bảo tính bảo mật trước khi công khai chúng. Quyết định nên được suy nghĩ trước - đảm bảo rằng với mỗi tài liệu, bạn ghi lại lượng độc giả được chấp nhận, ngày tạo và lý tưởng nhất là ngày hết hạn. Lưu siêu dữ liệu này.

Chà, chúng tôi phát hiện ra rằng chúng tôi cần di chuyển các tập tin...

Đây là một trong những lời bào chữa thảm hại nhất. Nhiều người không biết rằng máy chủ web cho phép bạn kiểm soát mối quan hệ giữa URI của một đối tượng và vị trí thực tế của nó trong hệ thống tệp. Hãy coi không gian URI như một không gian trừu tượng, được tổ chức hoàn hảo. Sau đó, hãy lập bản đồ tới bất kỳ thực tế nào mà bạn thực sự sử dụng để nhận ra nó. Sau đó báo cáo điều này với máy chủ web. Bạn thậm chí có thể viết đoạn mã máy chủ của riêng mình để làm cho nó đúng.

John không còn lưu giữ tập tin này nữa, Jane bây giờ thì có.

Tên của John có trong URI không? Không, có phải tập tin đó chỉ có trong thư mục của anh ấy không? Được rồi.

Trước đây chúng tôi sử dụng tập lệnh CGI cho việc này, nhưng bây giờ chúng tôi sử dụng chương trình nhị phân.

Có một ý tưởng điên rồ là các trang được tạo bởi tập lệnh phải được đặt trong khu vực "cgibin" hoặc "cgi". Điều này cho thấy cơ chế hoạt động của máy chủ web của bạn. Bạn thay đổi cơ chế (ngay cả khi đang lưu nội dung) và rất tiếc - tất cả các URI của bạn đều thay đổi.

Lấy Quỹ Khoa học Quốc gia (NSF) làm ví dụ:

Tài liệu trực tuyến NSF

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

Trang đầu tiên để bắt đầu xem tài liệu rõ ràng sẽ không còn như cũ sau một vài năm nữa. cgi-bin, oldbrowse и pl - tất cả điều này cung cấp một số thông tin về cách thức chúng tôi thực hiện ngay bây giờ. Nếu bạn sử dụng trang này để tìm kiếm tài liệu, kết quả đầu tiên bạn nhận được cũng tệ không kém:

Báo cáo của Nhóm công tác về Mật mã học và Lý thuyết mã hóa

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

đối với trang chỉ mục tài liệu, mặc dù bản thân tài liệu html trông đẹp hơn nhiều:

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

Ở đây, tiêu đề pubs/1998 sẽ cung cấp cho bất kỳ dịch vụ lưu trữ nào trong tương lai một manh mối tốt rằng sơ đồ phân loại tài liệu cũ năm 1998 đang có hiệu lực. Mặc dù số tài liệu có thể trông khác vào năm 2098, nhưng tôi cho rằng URI này vẫn hợp lệ và sẽ không can thiệp vào NSF hoặc bất kỳ tổ chức nào khác sẽ duy trì kho lưu trữ.

Tôi không nghĩ URL phải liên tục - đã có URN.

Đây có lẽ là một trong những tác dụng phụ tồi tệ nhất của cuộc tranh luận về URN. Một số người cho rằng do đang nghiên cứu về một không gian tên lâu dài hơn nên họ có thể bất cẩn với các liên kết treo lủng lẳng vì "URN sẽ khắc phục tất cả những điều đó". Nếu bạn là một trong những người này thì hãy để tôi làm bạn thất vọng.

Hầu hết các lược đồ URN mà tôi từng thấy trông giống như một mã định danh cơ quan, theo sau là ngày và chuỗi bạn chọn hoặc chỉ là một chuỗi bạn chọn. Điều này rất giống với URI HTTP. Nói cách khác, nếu bạn cho rằng tổ chức của mình có khả năng tạo các URN tồn tại lâu dài thì hãy chứng minh điều đó ngay bây giờ bằng cách sử dụng chúng cho các URI HTTP của bạn. Không có gì trong HTTP khiến URI của bạn không ổn định. Chỉ có tổ chức của bạn. Tạo cơ sở dữ liệu ánh xạ URN của tài liệu tới tên tệp hiện tại và cho phép máy chủ web sử dụng nó để thực sự truy xuất các tệp.

Nếu bạn đã đạt đến điểm này, nếu bạn không có thời gian, tiền bạc và mối quan hệ để phát triển một số phần mềm, thì bạn có thể đưa ra lý do sau:

Chúng tôi muốn, nhưng chúng tôi không có công cụ phù hợp.

Nhưng bạn có thể thông cảm với điều này. Tôi hoàn toàn đồng ý. Những gì bạn cần làm là buộc máy chủ web phân tích cú pháp ngay lập tức URI liên tục và trả lại tệp ở bất kỳ nơi nào nó hiện được lưu trữ trên hệ thống tệp điên rồ hiện tại của bạn. Bạn muốn lưu trữ tất cả các URI trong một tệp dưới dạng kiểm tra và luôn cập nhật cơ sở dữ liệu. Bạn muốn duy trì mối quan hệ giữa các phiên bản và bản dịch khác nhau của cùng một tài liệu, đồng thời duy trì một bản ghi tổng kiểm tra độc lập để đảm bảo rằng tệp không bị hỏng do lỗi vô tình. Và các máy chủ web đơn giản là không có những tính năng này. Khi bạn muốn tạo một tài liệu mới, trình soạn thảo của bạn sẽ yêu cầu bạn chỉ định một URI.

Bạn cần có khả năng thay đổi quyền sở hữu, quyền truy cập tài liệu, bảo mật cấp độ lưu trữ, v.v. trong không gian URI mà không thay đổi URI.

Tất cả đều quá tệ. Nhưng chúng tôi sẽ khắc phục tình hình. Tại W3C, chúng tôi sử dụng chức năng Jigedit (máy chủ chỉnh sửa Jigsaw) để theo dõi các phiên bản và chúng tôi thử nghiệm các tập lệnh tạo tài liệu. Nếu bạn phát triển công cụ, máy chủ và máy khách, hãy chú ý đến vấn đề này!

Lý do này cũng áp dụng cho nhiều trang W3C, bao gồm cả trang này: hãy làm như tôi nói, không phải như tôi làm.

Tại sao tôi nên quan tâm?

Khi thay đổi URI trên máy chủ của mình, bạn không bao giờ có thể biết hoàn toàn ai sẽ có liên kết đến URI cũ. Đây có thể là các liên kết từ các trang web thông thường. Đánh dấu trang của bạn. URI có thể đã được viết nguệch ngoạc bên lề một bức thư gửi cho bạn bè.

Khi ai đó truy cập một liên kết và nó bị hỏng, họ thường mất niềm tin vào chủ sở hữu máy chủ. Anh ấy cũng thất vọng, cả về mặt cảm xúc lẫn thể chất, vì không thể đạt được mục tiêu của mình.

Rất nhiều người liên tục phàn nàn về các liên kết bị hỏng và tôi hy vọng thiệt hại là rõ ràng. Tôi hy vọng rằng thiệt hại về mặt danh tiếng đối với người duy trì máy chủ nơi tài liệu biến mất cũng là điều hiển nhiên.

Vậy tôi nên làm gì? thiết kế URI

Quản trị viên web có trách nhiệm phân bổ các URI có thể được sử dụng trong 2 năm, 20 năm, 200 năm. Điều này đòi hỏi sự chu đáo, tổ chức và quyết tâm.

URI thay đổi nếu có bất kỳ thông tin nào trong đó thay đổi. Cách bạn thiết kế chúng là rất quan trọng. (Cái gì, thiết kế URI? Tôi có cần thiết kế URI không? Có, bạn nên suy nghĩ về điều đó). Thiết kế về cơ bản có nghĩa là loại bỏ bất kỳ thông tin nào trong URI.

Ngày tạo tài liệu - ngày URI được phát hành - là ngày không bao giờ thay đổi. Nó rất hữu ích để tách các truy vấn sử dụng hệ thống mới khỏi các truy vấn sử dụng hệ thống cũ. Đây là nơi tốt để bắt đầu với URI. Nếu một tài liệu đã cũ, ngay cả khi tài liệu đó có liên quan trong tương lai thì đây là một khởi đầu tốt.

Ngoại lệ duy nhất là một trang được cố ý là phiên bản "mới nhất", chẳng hạn như cho toàn bộ tổ chức hoặc phần lớn tổ chức đó.

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

Đây là chuyên mục Money Daily mới nhất trên tạp chí Money. Lý do chính không cần có ngày trong URI này là không có lý do gì để lưu trữ URI sẽ tồn tại lâu hơn nhật ký. Khái niệm Tiền Hàng Ngày sẽ biến mất khi Tiền biến mất. Nếu bạn muốn liên kết đến nội dung, bạn nên liên kết riêng với nội dung đó trong kho lưu trữ:

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

(Có vẻ ổn. Giả sử rằng "tiền" sẽ có ý nghĩa giống nhau trong suốt vòng đời của pathfinder.com. Có một "98" trùng lặp và một ".html" không cần thiết, nhưng mặt khác trông giống như một URI mạnh.

Những gì nên bỏ qua một bên

Tất cả! Ngoài ngày tạo, việc đưa bất kỳ thông tin nào vào URI sẽ gây ra rắc rối theo cách này hay cách khác.

Tên tác giả. Quyền tác giả có thể thay đổi khi có phiên bản mới. Mọi người rời khỏi tổ chức và truyền lại mọi thứ cho người khác.
Vấn đề. Nó rất khó. Lúc đầu nó luôn có vẻ tốt, nhưng thay đổi nhanh chóng một cách đáng ngạc nhiên. Tôi sẽ nói thêm về điều này dưới đây.
Trạng thái. Các thư mục như "cũ", "bản nháp", v.v., chưa kể "mới nhất" và "ngầu", xuất hiện trong tất cả các hệ thống tệp. Tài liệu thay đổi trạng thái - nếu không thì việc tạo bản nháp sẽ chẳng có ý nghĩa gì. Phiên bản mới nhất của tài liệu cần có mã định danh liên tục, bất kể trạng thái của nó. Giữ trạng thái ra khỏi tên.
Truy cập. Tại W3C, chúng tôi đã chia trang web thành các phần dành cho nhân viên, thành viên và công chúng. Điều này nghe có vẻ hay, nhưng tất nhiên, các tài liệu bắt đầu từ ý tưởng nhóm của nhân viên, được thảo luận với các thành viên và sau đó trở thành kiến thức công cộng. Sẽ thực sự đáng tiếc nếu mỗi lần một tài liệu được mở ra để thảo luận rộng rãi hơn thì tất cả các liên kết cũ tới nó đều bị hỏng! Bây giờ chúng ta chuyển sang mã ngày tháng đơn giản.
Phần mở rộng tệp. Một hiện tượng rất phổ biến. "cgi", thậm chí ".html" sẽ thay đổi trong tương lai. Bạn có thể không sử dụng HTML cho trang này trong 20 năm nữa, nhưng các liên kết đến trang này ngày nay vẫn hoạt động. Các liên kết chuẩn trên trang W3C không sử dụng phần mở rộng (làm thế nào nó được thực hiện).
Cơ chế phần mềm. Trong URI, hãy tìm "cgi", "exec" và các thuật ngữ khác có nội dung "hãy xem chúng tôi đang sử dụng phần mềm nào". Có ai muốn dành cả đời mình để viết kịch bản Perl CGI không? KHÔNG? Sau đó xóa phần mở rộng .pl. Đọc hướng dẫn sử dụng máy chủ về cách thực hiện việc này.
Tên đĩa. Cố lên! Nhưng tôi đã nhìn thấy điều này.

Vì vậy, ví dụ tốt nhất từ trang web của chúng tôi chỉ đơn giản là

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

... báo cáo về biên bản cuộc họp Chủ tịch W3C.

Chủ đề và phân loại theo chủ đề

Tôi sẽ đi vào chi tiết hơn về mối nguy hiểm này, vì đây là một trong những điều khó tránh nhất. Thông thường, các chủ đề sẽ xuất hiện trong URI khi bạn phân loại tài liệu của mình theo công việc chúng thực hiện. Nhưng sự cố này sẽ thay đổi theo thời gian. Tên của các khu vực sẽ thay đổi. Tại W3C, chúng tôi muốn thay đổi MarkUP thành Markup và sau đó thành HTML để phản ánh nội dung thực tế của phần này. Ngoài ra, thường có một không gian tên phẳng. Trong 100 năm nữa, bạn có chắc mình sẽ không muốn tái sử dụng bất cứ thứ gì không? Ví dụ: trong cuộc đời ngắn ngủi của mình, chúng tôi đã muốn sử dụng lại "Lịch sử" và "Bảng định kiểu".

Đó là một cách hấp dẫn để sắp xếp một trang web—và một cách thực sự hấp dẫn để sắp xếp mọi thứ, kể cả toàn bộ trang Web. Đây là giải pháp trung hạn rất tốt nhưng lại có những bất cập nghiêm trọng về lâu dài.

Một phần nguyên nhân nằm ở triết lý về ý nghĩa. Mỗi thuật ngữ trong một ngôn ngữ đều là mục tiêu tiềm năng để phân cụm và mỗi người có thể có ý tưởng khác nhau về ý nghĩa của nó. Vì mối quan hệ giữa các thực thể giống một cái mạng hơn là một cái cây, nên ngay cả những người đồng ý với trang web cũng có thể chọn một cách trình bày khác cho cái cây. Đây là những quan sát chung (thường được lặp lại) của tôi về sự nguy hiểm của việc phân loại theo thứ bậc như một giải pháp chung.

Trên thực tế, khi bạn sử dụng tên chủ đề trong URI, bạn đang tự cam kết tuân theo một số loại phân loại. Có lẽ trong tương lai bạn sẽ thích một lựa chọn khác. URI sau đó sẽ dễ bị vi phạm.

Lý do sử dụng một vùng chủ đề như một phần của URI là trách nhiệm đối với các phần phụ của không gian URI thường được ủy quyền và khi đó bạn cần tên của cơ quan tổ chức - bộ phận, nhóm hoặc bất kỳ tên nào - chịu trách nhiệm cho không gian con đó. Đây là một URI ràng buộc với một cơ cấu tổ chức. Thông thường chỉ an toàn nếu URI xa hơn (bên trái) được bảo vệ theo ngày: 1998/pics có thể có nghĩa đối với máy chủ của bạn "điều chúng tôi muốn nói vào năm 1998 với các bức ảnh" thay vì "những gì chúng tôi đã làm vào năm 1998 với những gì chúng tôi gọi là các bức ảnh".

Đừng quên tên miền

Hãy nhớ rằng điều này không chỉ áp dụng cho đường dẫn trong URI mà còn áp dụng cho tên máy chủ. Nếu bạn có các máy chủ riêng biệt cho những thứ khác nhau, hãy nhớ rằng sự phân chia này sẽ không thể thay đổi nếu không phá hủy rất nhiều liên kết. Một số lỗi kinh điển khi "xem phần mềm chúng tôi sử dụng ngày nay" là tên miền "cgi.pathfinder.com", "secure", "lists.w3.org". Chúng được thiết kế để giúp việc quản trị máy chủ trở nên dễ dàng hơn. Bất kể tên miền đại diện cho một bộ phận trong công ty của bạn, trạng thái tài liệu, cấp độ truy cập hay cấp độ bảo mật, hãy hết sức cẩn thận trước khi sử dụng nhiều tên miền cho nhiều loại tài liệu. Hãy nhớ rằng bạn có thể ẩn nhiều máy chủ web bên trong một máy chủ web hiển thị duy nhất bằng cách sử dụng tính năng chuyển hướng và ủy quyền.

Ồ, và cũng hãy nghĩ về tên miền của bạn. Bạn không muốn bị gọi là Soap.com sau khi bạn thay đổi dòng sản phẩm và ngừng sản xuất xà phòng (Xin lỗi những ai sở hữu Soap.com vào lúc này).

Kết luận

Việc duy trì URI trong 2, 20, 200 hoặc thậm chí 2000 năm rõ ràng không dễ dàng như người ta tưởng. Tuy nhiên, trên khắp Internet, các quản trị viên web đang đưa ra những quyết định khiến nhiệm vụ này thực sự khó khăn đối với họ trong tương lai. Thông thường, điều này là do họ sử dụng các công cụ có nhiệm vụ chỉ hiển thị trang web tốt nhất vào thời điểm hiện tại - và không ai đánh giá được điều gì sẽ xảy ra với các liên kết khi mọi thứ thay đổi. Tuy nhiên, vấn đề ở đây là rất nhiều thứ có thể thay đổi và URI của bạn có thể và nên giữ nguyên. Điều này chỉ có thể thực hiện được khi bạn nghĩ về cách bạn tạo ra chúng.

Xem thêm:

Bài chỉ trích của Jakob Nielsen về cùng chủ đề

Bổ sung

Cách xóa phần mở rộng của tập tin...

...từ một URI trong máy chủ web dựa trên tệp hiện tại?

Ví dụ: nếu bạn sử dụng Apache, bạn có thể định cấu hình nó để thương lượng nội dung. Lưu phần mở rộng tệp (ví dụ: .png) vào một tệp (ví dụ: mydog.png), nhưng bạn có thể liên kết tới một tài nguyên web mà không cần đến nó. Sau đó, Apache kiểm tra thư mục để tìm tất cả các tệp có tên đó và bất kỳ phần mở rộng nào, đồng thời có thể chọn tệp tốt nhất từ bộ (ví dụ: GIF và PNG). Và không cần phải đặt các loại tệp khác nhau vào các thư mục khác nhau, thực tế việc khớp nội dung sẽ không có tác dụng nếu bạn làm như vậy.

Thiết lập máy chủ của bạn để đàm phán nội dung
Luôn liên kết tới URI mà không cần phần mở rộng

Các liên kết có tiện ích mở rộng sẽ vẫn hoạt động nhưng sẽ ngăn máy chủ của bạn chọn định dạng tốt nhất hiện có và trong tương lai.

(Trong thực tế, mydog, mydog.png и mydog.gif - tài nguyên web hợp lệ, mydog là tài nguyên loại nội dung phổ quát và mydog.png и mydog.gif - tài nguyên của một loại nội dung cụ thể).

Tất nhiên, nếu bạn đang viết máy chủ web của riêng mình thì bạn nên sử dụng cơ sở dữ liệu để liên kết các mã định danh liên tục với dạng hiện tại của chúng, mặc dù hãy cẩn thận với việc tăng trưởng cơ sở dữ liệu không giới hạn.

Bảng Xấu hổ - Truyện 1: Kênh 7

Trong năm 1999, tôi đã theo dõi việc đóng cửa trường học do tuyết trên trang http://www.whdh.com/stormforce/closings.shtml. Đừng đợi thông tin xuất hiện ở cuối màn hình TV! Tôi liên kết với nó từ trang chủ của tôi. Cơn bão tuyết lớn đầu tiên của năm 2000 ập đến và tôi kiểm tra trang này. Nó được viết ở đó:,

- Kể từ đó.
Hiện tại không có gì bị đóng cửa. Vui lòng quay lại trong trường hợp có cảnh báo thời tiết.

Không thể có cơn bão mạnh như vậy được. Thật buồn cười là ngày tháng bị thiếu. Nhưng nếu bạn vào trang chính của trang web, sẽ có một nút lớn “Trường học đóng cửa”, dẫn đến trang http://www.whdh.com/stormforce/ với một danh sách dài các trường học đóng cửa.

Có thể họ đã thay đổi hệ thống lấy danh sách - nhưng họ không cần thay đổi URI.

Bảng xấu hổ - Câu chuyện 2: Buổi họp trực tuyến của Microsoft

Với sự phụ thuộc ngày càng tăng vào Internet, một ý tưởng thông minh đã nảy sinh là các liên kết tới trang web của nhà sản xuất có thể được nhúng vào các ứng dụng. Điều này đã được sử dụng và lạm dụng rất nhiều, nhưng bạn không thể thay đổi URL. Mới hôm nọ, tôi đã thử liên kết từ ứng dụng khách Microsoft Netmeeting 2/thứ gì đó trong menu Trợ giúp/Microsoft trên Web/Nội dung miễn phí và nhận được lỗi 404 - không tìm thấy phản hồi nào từ máy chủ. Có lẽ nó đã được sửa rồi...

Ghi chú lịch sử: Vào cuối thế kỷ 20, khi điều này được viết ra, "ngầu" là hình ảnh thu nhỏ của sự tán thành, đặc biệt là trong giới trẻ, biểu thị tính thời trang, chất lượng hoặc sự phù hợp. Trong lúc vội vàng, đường dẫn URI thường được chọn vì sự “mát mẻ” hơn là tính hữu dụng hay độ bền. Bài đăng này là một nỗ lực nhằm chuyển hướng năng lượng đằng sau việc tìm kiếm sự thú vị.

Nguồn: www.habr.com

URI thú vị không thay đổi