Fajne URI się nie zmieniają

Autor: Sir Tim Berners-Lee, wynalazca identyfikatorów URI, adresów URL, HTTP, HTML i sieci WWW oraz obecny szef W3C. Artykuł napisany w 1998 roku

Jaki URI jest uważany za „fajny”?
Taki, który się nie zmienia.
Jak zmieniają się identyfikatory URI?
Identyfikatory URI się nie zmieniają: ludzie je zmieniają.

Teoretycznie nie ma powodu, aby ludzie zmieniali URI (lub zaprzestali wspierania dokumentów), ale w praktyce są ich miliony.

Teoretycznie nominalny właściciel przestrzeni nazw domeny w rzeczywistości jest właścicielem przestrzeni nazw domeny, a zatem wszystkich znajdujących się w niej identyfikatorów URI. Poza niewypłacalnością nic nie stoi na przeszkodzie, aby właściciel domeny mógł ją zatrzymać. Teoretycznie przestrzeń URI pod nazwą Twojej domeny jest całkowicie pod Twoją kontrolą, więc możesz ustawić ją tak stabilnie, jak chcesz. Właściwie jedyną dobrą przyczyną zniknięcia dokumentu z Internetu jest fakt, że firma będąca właścicielem nazwy domeny zbankrutowała lub nie stać jej już na utrzymanie serwera. Dlaczego więc na świecie jest tak wiele brakujących ogniw? Część z nich wynika po prostu z braku przezorności. Oto kilka powodów, które możesz usłyszeć:

Właśnie przeorganizowaliśmy witrynę, aby była lepsza.

Czy naprawdę myślisz, że stare identyfikatory URI nie mogą już działać? Jeśli tak, to wybrałeś je bardzo źle. Rozważ zachowanie nowych do czasu kolejnej przebudowy.

Mamy tak dużo rzeczy, że nie jesteśmy w stanie śledzić, co jest nieaktualne, co jest poufne, a co nadal aktualne, więc pomyśleliśmy, że najlepiej będzie po prostu to wszystko wyłączyć.

Mogę tylko współczuć. W3C przeszło przez okres, w którym musieliśmy dokładnie przeglądać materiały archiwalne pod kątem poufności przed ich upublicznieniem. Decyzję należy przemyśleć z wyprzedzeniem – pamiętaj o tym, aby przy każdym dokumencie zanotować dopuszczalną czytelnictwo, datę powstania i, w idealnym przypadku, datę ważności. Zapisz te metadane.

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

To jedna z najbardziej żałosnych wymówek. Wiele osób nie wie, że serwery WWW pozwalają kontrolować relację pomiędzy URI obiektu a jego rzeczywistą lokalizacją w systemie plików. Pomyśl o przestrzeni URI jako o przestrzeni abstrakcyjnej, doskonale zorganizowanej. Następnie wykonaj mapowanie do dowolnej rzeczywistości, której faktycznie używasz, aby to zrealizować. Następnie zgłoś to serwerowi WWW. Możesz nawet napisać własny fragment kodu serwera, aby zrobić to dobrze.

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

Czy imię Johna znajdowało się w URI? Nie, czy plik znajdował się właśnie w jego katalogu? Cóż, OK.

Wcześniej używaliśmy do tego skryptu CGI, ale teraz używamy programu binarnego.

Istnieje szalony pomysł, aby strony tworzone za pomocą skryptów znajdowały się w obszarze „cgibin” lub „cgi”. To ujawnia mechanikę działania serwera WWW. Zmieniasz mechanizm (nawet podczas zapisywania treści) i ups – zmieniają się wszystkie Twoje URI.

Weźmy na przykład Narodową Fundację Nauki (NSF):

Dokumenty internetowe NSF

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

Pierwsza strona, na której rozpocznie się przeglądanie dokumentów, z pewnością nie będzie taka sama za kilka lat. cgi-bin, oldbrowse и pl - wszystko to dostarcza fragmentów informacji o tym, jak-robimy-to-teraz. Jeśli użyjesz strony do wyszukiwania dokumentu, pierwszy wynik, jaki otrzymasz, będzie równie zły:

Raport Grupy Roboczej ds. Kryptologii i Teorii Kodowania

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

dla strony indeksu dokumentu, chociaż sam dokument HTML wygląda znacznie lepiej:

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

Tutaj nagłówek pubs/1998 da przyszłym służbom archiwalnym dobrą wskazówkę, że obowiązuje stary schemat klasyfikacji dokumentów z 1998 roku. Chociaż numery dokumentów mogą wyglądać inaczej w 2098 r., wyobrażam sobie, że ten URI byłby nadal ważny i nie kolidowałby z NSF ani żadną inną organizacją utrzymującą archiwum.

Nie sądziłem, że adresy URL muszą być trwałe - były adresy URN.

Jest to prawdopodobnie jeden z najgorszych skutków ubocznych debaty na temat URN. Niektórzy uważają, że w związku z badaniami nad bardziej trwałą przestrzenią nazw mogą nie zwracać uwagi na 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 organu, po którym następuje data i wybrany ciąg znaków lub po prostu wybrany ciąg. Jest to bardzo podobne do identyfikatora URI HTTP. Innymi słowy, jeśli uważasz, że Twoja organizacja będzie w stanie tworzyć długotrwałe identyfikatory URN, udowodnij to teraz, używając ich w swoich identyfikatorach URI HTTP. W samym HTTP nie ma nic, co sprawiałoby, że Twój URI był niestabilny. Tylko Twoja organizacja. Utwórz bazę danych, która mapuje numer URN dokumentu na bieżącą nazwę pliku i pozwól serwerowi WWW użyć jej do faktycznego pobrania plików.

Jeśli dotarłeś do tego punktu, jeśli nie masz czasu, pieniędzy i kontaktów, aby opracować oprogramowanie, możesz podać następującą wymówkę:

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

Ale można mu współczuć. Całkowicie się zgadzam. To, co musisz zrobić, to zmusić serwer WWW do natychmiastowego przeanalizowania trwałego identyfikatora URI i zwrócenia pliku tam, gdzie jest on obecnie przechowywany w bieżącym szalonym systemie plików. Chcesz przechowywać wszystkie identyfikatory URI w pliku w celach kontrolnych i stale aktualizować bazę danych. Chcesz zachować powiązania między różnymi wersjami i tłumaczeniami tego samego dokumentu, a także prowadzić niezależny zapis sumy kontrolnej, aby mieć pewność, że plik nie zostanie uszkodzony przez przypadkowy błąd. A serwery internetowe po prostu nie są dostarczane z tymi funkcjami od razu po wyjęciu z pudełka. Gdy chcesz utworzyć nowy dokument, edytor poprosi Cię o podanie identyfikatora URI.

Musisz mieć możliwość zmiany właściciela, dostępu do dokumentów, bezpieczeństwa na poziomie archiwum itp. w przestrzeni URI bez zmiany URI.

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

Ta wymówka ma również zastosowanie do wielu stron W3C, łącznie z tą: róbcie to, co mówię, a nie to, co robię.

Czemu miało by mi zależeć?

Kiedy zmieniasz URI na swoim serwerze, nigdy nie możesz całkowicie stwierdzić, kto będzie miał linki do starego URI. Mogą to być linki ze zwykłych stron internetowych. Dodaj swoją stronę do zakładek. Identyfikator URI mógł zostać nabazgrany na marginesie listu do przyjaciela.

Gdy ktoś kliknie link, który ulegnie uszkodzeniu, zwykle traci zaufanie do właściciela serwera. Jest także sfrustrowany, zarówno emocjonalnie, jak i fizycznie, ponieważ nie jest w stanie osiągnąć swojego celu.

Wiele osób ciągle narzeka na niedziałające linki i mam nadzieję, że szkody są oczywiste. Mam nadzieję, że szkoda na reputację opiekuna serwera, na którym zniknął dokument, jest również oczywista.

Więc co powinienem zrobić? Projekt URI

Webmaster jest odpowiedzialny za przydzielenie identyfikatorów URI, które można wykorzystać za 2 lata, za 20 lat, za 200 lat. Wymaga to rozwagi, organizacji i determinacji.

Identyfikatory URI zmieniają się, jeśli jakiekolwiek zawarte w nich informacje ulegną zmianie. Bardzo ważny jest sposób ich zaprojektowania. (Co, projekt URI? Czy muszę projektować URI? Tak, powinieneś o tym pomyśleć). Projektowanie zasadniczo oznacza pominięcie wszelkich informacji w identyfikatorze URI.

Data utworzenia dokumentu – data wydania identyfikatora URI – to coś, co nigdy się nie zmieni. Jest to bardzo przydatne do oddzielenia zapytań korzystających z nowego systemu od zapytań korzystających ze starego systemu. To dobre miejsce na rozpoczęcie od identyfikatora URI. Jeśli dokument jest przestarzały, nawet jeśli będzie istotny w przyszłości, jest to dobry początek.

Jedynym wyjątkiem jest strona, która celowo jest w wersji „najnowszej”, np. dla całej organizacji lub jej dużej części.

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

Oto najnowszy felieton Money Daily w magazynie Money. Głównym powodem, dla którego nie ma potrzeby podawania daty w tym URI, jest brak powodu do przechowywania identyfikatora URI, który przetrwałby dłużej niż dziennik. Koncepcja Money Daily zniknie, gdy znikną pieniądze. Jeśli chcesz zamieścić link do treści, powinieneś umieścić link do niej oddzielnie w archiwum:

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

(Wygląda nieźle. Zakłada się, że „pieniądze” będą oznaczać to samo przez cały okres istnienia pathfinder.com. Jest duplikat „98” i niepotrzebny „.html”, ale poza tym wygląda to na silny identyfikator URI.

Co odłożyć na bok

Wszystko! Oprócz daty utworzenia, umieszczenie jakichkolwiek informacji w URI powoduje kłopoty w ten czy inny sposób.

  • Imię autora. Autorstwo może ulec zmianie w miarę udostępniania nowych wersji. Ludzie opuszczają organizacje i przekazują rzeczy innym.
  • Temat. To jest bardzo trudne. Na początku zawsze wygląda dobrze, ale zmienia się zaskakująco szybko. Opowiem o tym więcej poniżej.
  • Status. Katalogi takie jak „stary”, „wersja robocza” i tak dalej, nie wspominając o „najnowszych” i „fajnych”, pojawiają się we wszystkich systemach plików. Dokumenty zmieniają status – w przeciwnym razie tworzenie wersji roboczych nie miałoby sensu. Najnowsza wersja dokumentu wymaga stałego identyfikatora, niezależnie od jego statusu. Trzymaj status poza nazwą.
  • оступ. W W3C podzieliliśmy witrynę na sekcje dla pracowników, członków i ogółu społeczeństwa. Brzmi to nieźle, ale oczywiście dokumenty zaczynają się od pomysłów zespołu od pracowników, są omawiane z członkami, a następnie stają się wiedzą publiczną. Byłoby naprawdę szkoda, gdyby za każdym razem, gdy dokument jest otwierany do szerszej dyskusji, wszystkie stare linki do niego były zrywane! Teraz przechodzimy do prostego kodu daty.
  • Rozszerzenie pliku. Bardzo częste zjawisko. „cgi”, nawet „.html” ulegną zmianie w przyszłości. Być może za 20 lat nie będziesz używać kodu HTML na tej stronie, ale dzisiejsze linki do tej strony powinny nadal działać. Linki kanoniczne na stronie W3C nie korzystają z rozszerzenia (jak to jest zrobione).
  • Mechanizmy oprogramowania. W identyfikatorze URI poszukaj „cgi”, „exec” i innych terminów krzyczących „spójrz, jakiego oprogramowania używamy”. Czy ktoś chce spędzić całe życie na pisaniu skryptów CGI w języku Perl? NIE? Następnie usuń rozszerzenie .pl. Przeczytaj instrukcję serwera, jak to zrobić.
  • Nazwa dysku. Pospiesz się! Ale widziałem to.

Najlepszym przykładem z naszej strony jest więc po prostu

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

... zgłoś protokół ze spotkania Przewodniczących W3C.

Tematy i klasyfikacja tematyczna

Omówię to niebezpieczeństwo bardziej szczegółowo, ponieważ jest to jedna z tych rzeczy, których najtrudniej uniknąć. Zazwyczaj tematy trafiają do identyfikatorów URI, gdy kategoryzujesz dokumenty według wykonywanej przez nie pracy. Ale ten podział będzie się zmieniać z biegiem czasu. Nazwy obszarów ulegną zmianie. W W3C chcieliśmy zmienić MarkUP na Markup, a następnie na HTML, aby odzwierciedlić rzeczywistą zawartość sekcji. Ponadto często istnieje płaska przestrzeń nazw. Czy za 100 lat jesteś pewien, że nie będziesz chciał niczego ponownie wykorzystać? W naszym krótkim życiu chcieliśmy już na przykład ponownie wykorzystać „Historię” i „Arkusze stylów”.

To kuszący sposób na uporządkowanie witryny internetowej — i naprawdę kuszący sposób na uporządkowanie czegokolwiek, łącznie z całą siecią. Jest to świetne rozwiązanie średnioterminowe, ale w dłuższej perspektywie ma poważne wady.

Częściowo leży to w filozofii znaczenia. Każdy termin w języku jest potencjalnym celem grupowania i każda osoba może mieć inne wyobrażenie o tym, co to oznacza. Ponieważ relacje między podmiotami bardziej przypominają sieć niż drzewo, nawet ci, którzy zgadzają się z siecią, mogą wybrać inną reprezentację drzewa. Oto moje (często powtarzane) ogólne spostrzeżenia na temat niebezpieczeństw związanych z klasyfikacją hierarchiczną jako rozwiązaniem ogólnym.

W rzeczywistości, gdy używasz nazwy tematu w URI, zobowiązujesz się do pewnego rodzaju klasyfikacji. Być może w przyszłości wolisz inną opcję. URI będzie wówczas podatny na naruszenia.

Powodem użycia obszaru tematycznego jako części URI jest to, że odpowiedzialność za podsekcje przestrzeni URI jest zwykle delegowana i wtedy potrzebna jest nazwa organu organizacyjnego – działu, grupy lub czegokolwiek innego – odpowiedzialnego za tę podprzestrzeń. Jest to identyfikator URI powiązany ze strukturą organizacyjną. Zwykle jest to bezpieczne tylko wtedy, gdy dalszy (lewy) URI jest chroniony datą: 1998/pics może oznaczać dla twojego serwera „co mieliśmy na myśli w 1998 roku, mówiąc o zdjęciach”, a nie „co w 1998 roku zrobiliśmy z tym, co teraz nazywamy zdjęciami”.

Nie zapomnij nazwy domeny

Pamiętaj, że dotyczy to nie tylko ścieżki w URI, ale także nazwy serwera. Jeśli masz osobne serwery do różnych rzeczy, pamiętaj, że tego podziału nie da się zmienić bez zniszczenia wielu, wielu linków. Klasycznymi błędami typu „spójrz na oprogramowanie, którego używamy dzisiaj” są nazwy domen „cgi.pathfinder.com”, „secure”, „lists.w3.org”. Mają one na celu ułatwienie administrowania serwerem. Niezależnie od tego, czy domena reprezentuje dział Twojej firmy, status dokumentu, poziom dostępu czy poziom bezpieczeństwa, zachowaj szczególną ostrożność przed użyciem więcej niż jednej nazwy domeny dla wielu typów dokumentów. Pamiętaj, że możesz ukryć wiele serwerów internetowych w jednym widocznym serwerze internetowym, korzystając z przekierowań i proxy.

Aha, pomyśl też o nazwie swojej domeny. Nie chcesz, żeby nazywano Cię mydłem.com po zmianie linii produktów i zaprzestaniu produkcji mydła (przepraszam każdego, kto jest obecnie właścicielem witryny mydło.com).

wniosek

Zachowanie identyfikatora URI przez 2, 20, 200, a nawet 2000 lat nie jest oczywiście tak proste, jak się wydaje. Jednak w całym Internecie webmasterzy podejmują decyzje, które w przyszłości naprawdę utrudniają im to zadanie. Często dzieje się tak dlatego, że korzystają z narzędzi, których zadaniem jest zaprezentowanie najlepszej strony tylko w danym momencie – i nikt nie ocenił, co stanie się z linkami, gdy wszystko się zmieni. Jednak chodzi o to, że wiele, wiele rzeczy może się zmienić, a Twoje identyfikatory URI mogą i powinny pozostać takie same. Jest to możliwe tylko wtedy, gdy pomyślisz o tym, jak je tworzysz.

Zobacz także:

Dodatki

Jak usunąć rozszerzenia plików...

...z identyfikatora URI bieżącego serwera WWW opartego na plikach?

Jeśli na przykład używasz Apache, możesz go skonfigurować do negocjowania treści. Zapisz rozszerzenie pliku (np. .png) do pliku (np. mój pies.png), ale bez niego możesz utworzyć łącze do zasobu internetowego. Następnie Apache sprawdza, czy w katalogu znajdują się wszystkie pliki o tej nazwie i dowolnym rozszerzeniu, i 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 dopasowywanie treści nie będzie działać, jeśli to zrobisz.

  • Skonfiguruj serwer do negocjowania treści
  • Zawsze łącz z identyfikatorami URI bez rozszerzenia

Linki z rozszerzeniami będą nadal działać, ale uniemożliwią Twojemu serwerowi wybór najlepszego dostępnego obecnie i w przyszłości formatu.

(W rzeczywistości, mydog, mydog.png и mydog.gif — aktualne zasoby sieciowe, mydog jest uniwersalnym zasobem typu treści, oraz mydog.png и mydog.gif — zasoby o określonym typie treści).

Oczywiście, jeśli piszesz własny serwer WWW, dobrym pomysłem jest wykorzystanie bazy danych do powiązania trwałych identyfikatorów z ich obecną formą, aczkolwiek uważaj na nieograniczony rozwój bazy danych.

Tablica wstydu - Historia 1: Kanał 7

W 1999 r. śledziłem na stronie informacje o zamknięciu szkół z powodu śniegu http://www.whdh.com/stormforce/closings.shtml. Nie czekaj, aż informacja pojawi się na dole ekranu telewizora! Podałem link do niego na mojej stronie głównej. Nadchodzi pierwsza wielka burza śnieżna w 2000 roku i sprawdzam stronę. Jest tam napisane:,

- Od.
Nic nie jest obecnie zamknięte. Prosimy o powrót w przypadku ostrzeżeń pogodowych.

To nie może być tak silna burza. To zabawne, że brakuje daty. Ale jeśli przejdziesz na stronę główną witryny, pojawi się duży przycisk „Zamknięte szkoły”, który prowadzi do strony http://www.whdh.com/stormforce/ z długą listą zamkniętych szkół.

Być może zmienili system uzyskiwania listy - ale nie musieli zmieniać identyfikatora URI.

Board of Shame - Historia 2: Spotkanie Microsoft Netmeeting

Wraz z rosnącą zależnością od Internetu pojawił się sprytny pomysł, aby w aplikacjach można było osadzić linki do strony producenta. Było to często używane i nadużywane, ale nie można zmienić adresu URL. Któregoś dnia wypróbowałem łącze z klienta Microsoft Netmeeting 2/coś w menu Pomoc/Microsoft w sieci Web/Bezpłatne rzeczy i otrzymałem błąd 404 – nie znaleziono odpowiedzi z serwera. Może już to naprawili...

© 1998 Tim BL

Notatka historyczna: pod koniec XX wieku, kiedy pisano tę książkę, „fajny” był epitetem aprobaty, szczególnie wśród młodych ludzi, wskazującym na modę, jakość lub stosowność. W pośpiechu ścieżkę URI często wybierano ze względu na „fajność”, a nie użyteczność lub trwałość. Ten post jest próbą przekierowania energii stojącej za poszukiwaniem cool.

Źródło: www.habr.com

Dodaj komentarz