Autor — sir Tim Berners-Lee, wynalazca URI, URL, HTTP, HTML i World Wide Web, obecny szef W3C. Artykuł napisany w 1998 roku.

Jaki URI można uznać za „fajny”?
Taki, który się nie zmienia.
Jak zmieniają się URI?
URI się nie zmieniają: zmieniają je ludzie.

Teoretycznie ludzie nie mają powodów do zmiany URI (ani do zaprzestania utrzymywania dokumentów), ale w praktyce są ich miliony.

Teoretycznie nominalny właściciel przestrzeni nazw domenowych rzeczywiście posiada tę przestrzeń i tym samym wszystkie URI w niej. Oprócz niewypłacalności nic nie przeszkadza właścicielowi domeny w jej utrzymaniu. I teoretycznie przestrzeń URI pod twoją nazwą domenową jest całkowicie pod twoją kontrolą, więc możesz uczynić ją tak stabilną, jak chcesz. W dużej mierze jedynym uzasadnionym powodem zniknięcia dokumentu z internetu jest to, że firma, która posiadała tę nazwę domenową, zakończyła działalność lub nie może już sobie pozwolić na utrzymanie serwera. Dlaczego zatem na świecie jest tak wiele martwych linków? Częściowo to po prostu brak przewidywania. Oto niektóre powody, które można usłyszeć:

Po prostu zreorganizowaliśmy naszą stronę, aby uczynić ją lepszą.

Naprawdę myślisz, że stare URI nie mogą już działać? Jeśli tak, to wybrałeś je bardzo źle. Pomyśl, aby nowe pozostały po następnej reorganizacji.

Mamy tak wiele materiału, że nie możemy śledzić, co jest przestarzałe, co jest poufne, a co wciąż aktualne, więc pomyśleliśmy, że lepiej po prostu wyłączyć to wszystko.

Mogę tylko wyrazić współczucie. W3C przeszło przez okres, w którym musieliśmy dokładnie sprawdzać materiały archiwalne pod kątem poufności, zanim udostępniliśmy je publicznie. Decyzje powinny być przemyślane z wyprzedzeniem — upewnij się, że rejestrujesz z każdym dokumentem akceptowalny krąg odbiorców, datę utworzenia i, w idealnym przypadku, termin ważności. Zachowaj te metadane.

Cóż, odkryliśmy, że musimy przenieść pliki…

To jedno z najgorszych usprawiedliwień. Wielu nie wie, że serwery WWW pozwalają zarządzać połączeniem między URI obiektu a jego rzeczywistą lokalizacją w systemie plików. Wyobraź sobie przestrzeń URI jako abstrakcyjną przestrzeń, idealnie uporządkowaną. Następnie wykonaj odwzorowanie na wszelką rzeczywistość, którą faktycznie wykorzystujesz do jej realizacji. A potem przekaż to serwerowi WWW. Możesz nawet napisać fragment swojego serwera, aby zrobić to poprawnie.

John już nie utrzymuje tego pliku, teraz robi to Jane.

Czy imię Johna było w URI? Nie, po prostu plik znajdował się w jego katalogu? Rozumiem.

Kiedyś używaliśmy do tego skryptu CGI, a teraz korzystamy z programu binarnego.

Istnieje szalona idea, że strony tworzone przez skrypty powinny być umieszczone w obszarze "cgibin" lub "cgi". To ujawnia mechanizm, jak uruchamiasz swój serwer internetowy. Zmieniasz mechanizm (nawet zachowując treść), i ups — wszystkie twoje URI się zmieniają.

Weźmy na przykład Narodowy Fundusz Nauki (NSF):

Dokumenty NSF online

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

Pierwsza strona do przeglądania dokumentów z pewnością nie będzie wyglądać tak samo za kilka lat. cgi-bin, oldbrowse i pl — wszystko to daje fragmenty informacji na temat tego, jak-to-robimy-teraz. Jeśli używasz strony do wyszukiwania dokumentu, otrzymujesz również tak samo słaby wynik:

Raport grupy roboczej ds. kryptologii i teorii kodowania

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

dla indeksowej strony dokumentu, chociaż sam dokument html wygląda znacznie lepiej:

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

Tutaj nagłówek pubs/1998 da każdemu przyszłemu archiwum dobry klucz do zrozumienia starych schematów klasyfikacji dokumentów z 1998 roku. Chociaż w 2098 roku numery dokumentów mogą wyglądać inaczej, to mogę sobie wyobrazić, że to URI wciąż będzie ważne i w żaden sposób nie zaszkodzi NSF ani innej organizacji, która będzie utrzymywać archiwum.

Nie sądziłem, że adresy URL powinny być trwałe — były przecież URN.

Prawdopodobnie jest to jeden z najgorszych efektów ubocznych dyskusji na temat URN. Niektórzy myślą, że z powodu badań dotyczących bardziej trwałej przestrzeni nazw mogą lekceważyć wiszące linki, ponieważ „URN to wszystko naprawi”. Jeśli jesteś jedną z tych osób, pozwól, że cię rozczaruję.

Większość schematów URN, które widziałem, wygląda jak identyfikator urzędowy, po którym następuje albo data i ciąg, który wybierasz, albo po prostu ciąg, który wybierasz. Przypomina to bardzo HTTP URI. Innymi słowy, jeśli myślisz, że twoja organizacja będzie w stanie tworzyć długotrwałe URN, udowodnij to teraz, używając ich do swoich HTTP URI. W samym HTTP nie ma nic, co czyniłoby twój URI niestabilnym. Tylko twoja organizacja. Stwórz bazę danych, która powiązuje URN dokumentu z aktualną nazwą pliku, i pozwól serwerowi WWW wykorzystać ją do rzeczywistego pobierania plików.

Jeśli dotarłeś do tego momentu, a jeśli nie masz czasu, pieniędzy i kontaktów, aby stworzyć jakieś oprogramowanie, możesz przedstawić następujące usprawiedliwienie:

Chcieliśmy, ale po prostu nie mamy odpowiednich narzędzi.

Niemniej można temu współczuć. Całkowicie się zgadzam. To, co musisz zrobić, to zmusić serwer WWW do natychmiastowego przetworzenia stałego URI i zwrócenia pliku, gdziekolwiek by się on w danym momencie znajdował w twoim szalonym systemie plików. Chcesz przechowywać wszystkie URI w pliku jako sprawdzenie i stale aktualizować bazę danych, aby była aktualna. Chcesz zachować relacje między różnymi wersjami i tłumaczeniami tego samego dokumentu, a także mieć niezależny zapis sumy kontrolnej, aby zapewnić ochronę przed uszkodzeniem pliku w wyniku przypadkowego błędu. A serwery WWW po prostu nie są wyposażone w te funkcje. Kiedy chcesz utworzyć nowy dokument, twój edytor prosi o podanie URI.

Potrzebujesz możliwości zmiany właścicielstwa, dostępu do dokumentu, poziomu bezpieczeństwa archiwum i innych w przestrzeni URI bez zmiany URI.

Wszystko jest zbyt złe. Ale naprawimy sytuację. W W3C wykorzystujemy funkcjonalność Jigedit (serwer Jigsaw do edycji), która śledzi wersje, i eksperymentujemy z skryptami tworzenia dokumentów. Jeśli tworzysz narzędzia, serwery i klientów, zwróć uwagę na ten problem!

To usprawiedliwienie odnosi się także do wielu stron W3C, w tym tej: więc rób to, co mówię, a nie to, co robię.

Dlaczego powinno mnie to obchodzić?

Kiedy zmieniasz URI na swoim serwerze, nigdy nie możesz w pełni powiedzieć, kto będzie miał linki do starego URI. Mogą to być linki z normalnych stron internetowych. Zakładki do twojej strony. URI mogło być zapisane na marginesach listu do przyjaciela.

Kiedy ktoś kliknie w link i jest on zepsuty, zazwyczaj traci zaufanie do właściciela serwera. Jest również zawiedziony – zarówno emocjonalnie, jak i rzeczywiście przez niemożność osiągnięcia celu.

Wielu ludzi ciągle narzeka na zepsute linki i mam nadzieję, że szkody są oczywiste. Mam również nadzieję, że widoczna jest reputacyjna szkoda dla administratora serwera, na którym zniknął dokument.

Co więc robić? Projektowanie URI.

Obowiązkiem webmastera jest projektowanie URI, które można będzie używać przez 2 lata, 20 lat, 200 lat. Wymaga to przemyślenia, organizacji i determinacji.

URI zmieniają się, jeśli w nich zmienia się jakaś informacja. Ważne jest, jak je projektujesz. (Co, projektowanie URI? Muszę projektować URI? Tak, powinieneś o tym pomyśleć). Projektowanie oznacza zasadniczo brak jakiejkolwiek informacji w URI.

Data utworzenia dokumentu – data wydania URI – to coś, co nigdy się nie zmieni. Jest to bardzo przydatne do oddzielania żądań, które korzystają z nowego systemu, od tych, które korzystają ze starego systemu. Dobrze jest zacząć URI od niej. Jeśli na dokumencie jest podana jakaś data, nawet jeśli dokument będzie aktualny w przyszłości, to dobry początek.

Jedynym wyjątkiem jest strona, która celowo jest „ostatnią” wersją, na przykład dla całej organizacji lub jej dużej części.

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

To ostatni artykuł Money Daily w magazynie Money. Głównym powodem, dla którego w tym URI nie potrzebna jest data, jest to, że nie ma żadnych powodów, by zachować URI, które przetrwa magazyn. Pojęcie Money Daily zniknie, gdy zniknie Money. Jeśli chcesz powołać się na treść, powinieneś powołać się na nią osobno w archiwach:

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

(Wygląda dobrze. Zakłada, że "money" będą oznaczać to samo przez cały czas istnienia pathfinder.com. Jest duplikacja "98" i niepotrzebne ".html", ale poza tym wygląda na silne URI.

Co zostawić na boku.

Wszystko! Poza datą utworzenia, umieszczając jakąkolwiek informację w URI, w pewien sposób zapraszasz kłopoty.

Imię autora. Autorstwo może się zmieniać wraz z nowymi wersjami. Ludzie opuszczają organizacje i przekazują przedmioty innym.
Przedmiot. To bardzo trudne. Zawsze dobrze się prezentuje na początku, ale zmienia się zdumiewająco szybko. Opowiem o tym więcej poniżej.
Status. W systemach plików pojawiają się katalogi typu 'stary', 'roboczy' i tym podobne, nie wspominając o 'ostatnim' i 'fajnym'. Dokumenty zmieniają status — w przeciwnym razie nie miałoby sensu tworzenie roboczych wersji. Ostatnia wersja dokumentu potrzebuje stałego identyfikatora, niezależnie od jego statusu. Trzymaj status z dala od nazwy.
Dostęp. W W3C podzieliliśmy stronę na sekcje dla pracowników, członków i publiczności. Brzmi dobrze, ale oczywiście dokumenty zaczynają się jako pomysły zespołu pracowników, są omawiane z członkami, a potem stają się ogólnie dostępne. Rzeczywiście, to przykre, gdy za każdym razem, gdy jakiś dokument jest otwierany do szerszej dyskusji, wszystkie stare linki do niego się łamią! Teraz przechodzimy do prostego kodu daty.
Rozszerzenie pliku. Bardzo powszechne zjawisko. "cgi", a nawet ".html" zmienią się w przyszłości. Może za 20 lat nie będziesz używać HTML dla tej strony, ale linki do niej muszą nadal działać. Kanoniczne linki na stronie W3C nie używają rozszerzenia (jak to się robi).
Mechanizmy programowe. W URI szukaj "cgi", "exec" i innych terminów, które krzyczą 'zobacz, jakie oprogramowanie używamy'. Czy ktoś chce poświęcić całe życie na skrypty Perl CGI? Nie? W takim razie usuń rozszerzenie .pl. Przeczytaj podręcznik serwera, jak to zrobić.
Nazwa dysku. No proszę! Ale widziałem coś takiego.

Więc najlepszy przykład z naszej strony to po prostu

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

… raport z protokołu posiedzenia przewodniczących W3C.

Tematy i klasyfikacja według tematów

Bardziej szczegółowo opowiem o tym zagrożeniu, ponieważ jest to jedna z rzeczy, które najtrudniej uniknąć. Zwykle tematy pojawiają się w URI, gdy klasyfikujesz swoje dokumenty według wykonywanej pracy. Jednak ta klasyfikacja zmieni się z czasem. Nazwy obszarów ulegną zmianie. W W3C chcieliśmy zmienić MarkUP na Markup, a następnie na HTML, aby odzwierciedlić faktyczną treść sekcji. Ponadto często występuje tu płaska przestrzeń nazw. Po 100 latach na pewno nie będziesz chciał niczego ponownie używać? W naszym krótkim życiu już chcieliśmy ponownie wykorzystać 'Historię' i 'Style', na przykład.

To kuszący sposób na organizację strony internetowej — i naprawdę kuszący sposób na organizację czegokolwiek, w tym całej Sieci. To świetne rozwiązanie średnioterminowe, ale ma poważne wady w dłuższym okresie.

Częściowo przyczyny tkwią w filozofii znaczenia. Każdy termin w języku jest potencjalnym obiektem klasteryzacji, a każda osoba może mieć różne wyobrażenie na temat tego, co on oznacza. Ponieważ relacje między podmiotami są bardziej podobne do sieci niż do drzewa, nawet ci, którzy zgadzają się z siecią, mogą mieć inną wizję drzewa. To moje (często powtarzane) ogólne uwagi na temat niebezpieczeństw hierarchicznej klasyfikacji jako ogólnego rozwiązania.

W rzeczywistości, gdy używasz nazwy tematu w URI, wiążesz się z pewną klasyfikacją. Możliwe, że w przyszłości wybierzesz inną opcję. W takim przypadku URI będzie naruszone.

Powodem używania obszaru tematycznego jako części URI jest to, że odpowiedzialność za podsekcje przestrzeni URI zazwyczaj jest delegowana, a wtedy potrzebujesz nazwy organu organizacyjnego — jednostki, grupy lub czegokolwiek innego, co odpowiada za tę podprzestrzeń. To wiązanie URI z strukturą organizacyjną. Zwykle jest to bezpieczne tylko wtedy, gdy dalej (po lewej) URI jest zabezpieczone datą: 1998/pics może oznaczać dla twojego serwera 'to, co mieliśmy na myśli w 1998 roku jako pics', a nie 'to, co w 1998 roku zrobiliśmy z tym, co teraz nazywamy pics'.

Nie zapomnij o nazwie domeny

Pamiętaj, że to dotyczy nie tylko ścieżki w URI, ale także nazwy serwera. Jeśli masz oddzielne serwery dla różnych rzeczy, pamiętaj, że to podział będzie niemożliwy do zmiany, nie niszcząc mnóstwa linków. Niektóre klasyczne błędy typu 'zobacz, jakie oprogramowanie używamy dzisiaj' — nazwy domen "cgi.pathfinder.com", "secure", "lists.w3.org". Zostały stworzone, aby ułatwić zarządzanie serwerami. Niezależnie od tego, czy domena reprezentuje jakieś oddział w twojej firmie, status dokumentu, poziom dostępu czy poziom bezpieczeństwa, bądź bardzo, bardzo ostrożny przed użyciem więcej niż jednej nazwy domeny dla różnych typów dokumentów. Pamiętaj, że możesz ukryć wiele serwerów internetowych wewnątrz jednego widocznego serwera internetowego, używając przekierowania i proxy.

Tak, i pomyśl również o swojej nazwie domeny. Nie chcesz, aby nazywano cię mydlo.com po tym, jak zmienisz linię produktów i przestaniesz produkować mydło (przepraszam osobę, która obecnie posiada soap.com).

Podsumowanie

Zachowanie URI przez 2, 20, 200 lub nawet 2000 lat oczywiście nie jest tak proste, jak się wydaje. Niemniej jednak, w całym internecie webmasterzy podejmują decyzje, które naprawdę utrudniają sobie to zadanie w przyszłości. Często dzieje się tak, ponieważ używają narzędzi, których celem jest predstawić najlepszą stronę tylko w danym momencie – i nikt nie ocenił, co stanie się z linkami, gdy wszystko się zmieni. Istotą jest to, że wiele, bardzo wiele może się zmienić, a twoje URI mogą i powinny pozostać takie same. Jest to możliwe tylko wtedy, gdy myślisz o tym, jak je tworzysz.

Zobacz także:

Tyrada Jakoba Nielsena na ten sam temat

Dodatki

Jak usunąć rozszerzenia plików…

…z URI w bieżącym serwerze WWW opartym na plikach?

Jeśli używasz, na przykład, Apache, możesz go skonfigurować tak, aby pasował do treści. Zachowujesz rozszerzenie pliku (np. .png) w pliku (np. mydog.png), ale można odwoływać się do zasobu internetowego i bez niego. Następnie Apache sprawdza katalog pod kątem wszystkich plików o tej nazwie i dowolnym rozszerzeniu, a także może wybrać najlepszy z zestawu (na przykład GIF i PNG). I nie ma potrzeby umieszczania różnych typów plików w różnych katalogach, w rzeczywistości negocjacja treści nie zadziała, jeśli to zrobisz.

Skonfiguruj swój serwer do negocjacji treści
Zawsze odwołuj się do URI bez rozszerzenia

Linki z rozszerzeniami będą nadal działać, ale nie pozwolą Twojemu serwerowi na wybór najlepszego z dostępnych w danej chwili i przyszłych formatów.

(W rzeczywistości, mydog, mydog.png i mydog.gif — to ważne zasoby internetowe, mydog — to zasób o uniwersalnym typie treści, a mydog.png i mydog.gif — to zasoby o konkretnym typie treści).

Oczywiście, jeśli piszesz własny serwer internetowy, dobrze jest użyć bazy danych do powiązania stałych identyfikatorów z ich aktualną formą, chociaż uważaj na nieograniczony wzrost bazy danych.

Tablica wstydu — Historia 1: Channel 7

W roku 1999 śledziłem zamknięcie szkół z powodu śniegu na stronie http://www.whdh.com/stormforce/closings.shtml. Nie będę czekać, aż informacja pojawi się na dole ekranu telewizora! Umieściłem na niej link na mojej stronie domowej. Nadeszła pierwsza wielka burza śnieżna roku 2000, i sprawdzam stronę. Jest napisane:

— Stan na.
W tej chwili nic nie jest zamknięte. Proszę wracać w przypadku ostrzeżeń pogodowych.

Nie może być, taki silny sztorm. Zabawne, że data jest pominięta. Ale jeśli przejdziesz na stronę główną, będzie tam duży przycisk „Zamknięte szkoły”, który prowadzi do strony http://www.whdh.com/stormforce/ z długą listą zamkniętych szkół.

Może zmienili system uzyskiwania listy — ale nie musieli zmieniać URI.

Tablica wstydu — Historia 2: Microsoft Netmeeting

W miarę jak rośnie zależność od internetu, pojawiła się mądra myśl, że w aplikacjach można osadzać linki do strony producenta. Często z tego korzystano i nadużywano, ale — nie można zmieniać URL. Dosłownie kilka dni temu próbowałem linku z klienta Microsoft Netmeeting 2/something w menu Pomoc/Microsoft w Internecie/Darmowe rzeczy i otrzymałem błąd 404 — brak odpowiedzi serwera. Może już naprawili...

Notatka historyczna: pod koniec XX wieku, kiedy to pisano, "fajnie" było określeniem aprobaty, szczególnie wśród młodzieży, wskazującym na modę, jakość lub stosowność. W pośpiechu często wybierano ścieżkę URI z powodu "fajności", a nie użyteczności czy trwałości. Ta notatka jest próbą skierowania energii stojącej za poszukiwaniem fajności.

Źródło: habr.com