Autor — Sir Tim Berners-Lee, inventatorul URI, URL, HTTP, HTML și al WWW, director activ al W3C. Articolul a fost scris în 1998.

Ce URI poate fi considerat «interesant»?
Cel care nu se schimbă.
Cum se schimbă URI-urile?
URI-urile nu se schimbă: oamenii le modifică.

În teorie, oamenii nu au motive să schimbe URI-urile (sau să înceteze să susțină documentele), dar în practică sunt milioane.

Teoretic, proprietarul nominal al unei zone de domeniu deține cu adevărat acea zonă și, prin urmare, toate URI-urile din ea. În afară de incapacitatea de plată, nimic nu împiedică proprietarul de domeniu să mențină acel nume. Și teoretic, spațiul URI sub numele dumneavoastră de domeniu este complet sub controlul dumneavoastră, așadar îl puteți face la fel de stabil cum doriți. În mare parte, singurul motiv serios pentru care un document poate dispărea de pe internet este că firma care deținea numele de domeniu a ieșit din afaceri sau nu mai poate susține funcționarea serverului. Atunci, de ce există atât de multe linkuri moarte în lume? Parțial este pur și simplu un deficit de previziune. Iată câteva motive pe care le putem auzi:

Am reorganizat site-ul pentru a-l face mai bun.

Chiar credeți că URI-urile vechi nu mai pot funcționa? Dacă da, ați făcut alegeri foarte proaste. Gândiți-vă să le păstrați pe cele noi după următorul redesign.

Avem atât de mult material încât nu putem să urmărim ce este depășit, ce este confidențial și ce este încă relevant, așa că am crezut că e mai bine să dezactivăm tot.

Pot doar să-mi exprim compasiunea. W3C a trecut printr-o perioadă în care a trebuit să analizăm atent materialele arhivate pentru confidențialitate înainte de a le face publice. Decizia trebuie să fie luată din timp — asigurați-vă că fixați cu fiecare document un cerc acceptabil de cititori, data creării și, ideal, durata de valabilitate. Păstrați aceste metadate.

Ei bine, am descoperit că trebuie să mutăm fișierele…

Aceasta este una dintre cele mai lamentabile scuze. Mulți nu știu că serverele web vă permit să gestionați legătura dintre URI-ul unui obiect și locația sa actuală în sistemul de fișiere. Imaginați-vă spațiul URI ca un spațiu abstract, perfect organizat. Apoi faceți o corespondență cu orice realitate pe care o folosiți pentru a o implementa. Apoi informați serverul web despre aceasta. Puteți chiar să scrieți un fragment din serverul vostru pentru a face totul corect.

John nu mai întreține acest fișier, acum Jane se ocupă de el.

Numele lui John era în URI? Nu, doar fișierul era în directorul lui? Aha, înțeleg.

În trecut, foloseam un script CGI pentru asta, iar acum folosim un program binar.

Există o idee nebunească că paginile create de scripturi ar trebui să fie amplasate în zona "cgibin" sau "cgi". Acest lucru dezvăluie modul în care rulați serverul web. Schimbați mecanismul (chiar păstrând conținutul) și ups — toate URI-urile dvs. se schimbă.

Să luăm, de exemplu, Fondul Național pentru Știință (NSF):

Documente online NSF

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

Prima pagină pentru a începe să vizualizați documentele nu va rămâne vizibilă la fel peste câțiva ani. cgi-bin, oldbrowse și pl — toate acestea oferă particule de informație despre cum-o-facem-acum. Dacă folosiți o pagină pentru a căuta un document, veți obține prima dată un rezultat la fel de prost:

Raportul Grupului de lucru pentru criptologie și teoria codării

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

pentru pagina de index a documentului, deși documentul html în sine arată mult mai bine:

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

Aici, titlul pubs/1998 va oferi oricărui serviciu de arhivare viitor o cheie bună pentru a înțelege că vechea schemă de clasificare a documentelor din 1998 este activă. Deși în 2098 numerele documentelor ar putea arăta diferit, îmi pot imagina că acest URI va fi în continuare valid și nu va deranja NSF sau orice altă organizație care va întreține arhiva.

Nu credeam că URL-urile trebuie să fie permanente — existau și URN-uri.

Probabil că acesta este unul dintre cele mai rele efecte secundare ale discuției despre URN-uri. Unii cred că din cauza cercetărilor despre un spațiu de nume mai permanent, pot fi neglijenți în ceea ce privește linkurile moarte, deoarece „URN-urile vor rezolva totul”. Dacă sunteți dintre acești oameni, permiteți-mi să vă dezamăgesc.

Majoritatea schemelor URN pe care le-am văzut arată ca un identificator de autoritate, urmat fie de o dată și un șir ales de tine, fie doar de un șir ales de tine. Este foarte asemănător cu un HTTP URI. Cu alte cuvinte, dacă credeți că organizația dumneavoastră va putea crea URN-uri durabile, dovediți acest lucru acum, folosindu-le pentru URI-urile dumneavoastră HTTP. În HTTP nu există nimic care să facă URI-ul dumneavoastră instabil. Doar organizația dumneavoastră. Creați o bază de date care asociază URN-ul documentului cu numele actual al fișierului și permiteți serverului web să o utilizeze pentru a extrage efectiv fișierele.

Dacă ați ajuns până aici, atunci dacă nu aveți timp, bani și conexiuni pentru a dezvolta un software, puteți invoca următoarea scuză:

Am fi vrut, dar pur și simplu nu avem instrumentele necesare.

Puteți avea compasiune pentru acest lucru. Sunt complet de acord. Ceea ce trebuie să faceți este să forțați serverul web să proceseze instantaneu URI-ul permanent și să returneze fișierul, indiferent de locul în care este deposit în prezent în sistemul dumneavoastră de fișiere dezordonat. Vreți să păstrați toate URI-urile într-un fișier ca validare și să mențineți constant baza de date actualizată. Vreți să păstrați relațiile între diferite versiuni și traduceri ale aceluiași document și să păstrați un fișier independent de sumă de control pentru a asigura protecția împotriva coruperii fișierului din cauza unei erori accidentale. Iar serverele web nu vin de la sine cu aceste funcționalități. Atunci când doriți să creați un document nou, editorul dumneavoastră va solicita să specificați un URI.

Aveți nevoie de capacitatea de a modifica proprietatea, accesul la document, nivelul de securitate a arhivei și altele în spațiul URI fără a modifica URI-ul.

Totul este prea rău. Dar vom corecta situația. În W3C folosim funcționalitatea Jigedit (server Jigsaw pentru editare), care urmărește versiunile, și experimentăm cu scripturi pentru crearea documentelor. Dacă dezvoltați instrumente, servere și clienți, luați în considerare această problemă!

Această scuză se aplică, de asemenea, multor pagini W3C, inclusiv aceasta: deci faceți ceea ce vă spun, nu ceea ce fac.

De ce ar trebui să mă preocupe asta?

Când schimbi URI-ul pe serverul tău, nu poți niciodată să știi complet cine va avea link-uri către vechiul URI. Acestea pot fi link-uri de pe pagini web obișnuite. Marcaje pe pagina ta. URI-ul ar fi putut fi scris pe marginea unei scrisori către un prieten.

Când cineva accesează un link și acesta este rupt, de obicei își pierde încrederea în proprietarul serverului. De asemenea, este dezamăgit - atât emoțional, cât și în mod real, din cauza imposibilității de a-și atinge scopul.

Multe persoane se plâng constant de link-uri rupte și sper că daunele sunt evidente. Sper că este, de asemenea, evidentă dauna reputațională pentru întreținătorul serverului de pe care a dispărut documentul.

Deci ce să fac? Designul URI-ului

Este responsabilitatea webmaster-ului să creeze URI-uri care vor putea fi folosite peste 2 ani, peste 20 de ani, peste 200 de ani. Pentru aceasta, sunt necesare gândire, organizare și determinare.

URI-urile se schimbă dacă informația conținută în ele se schimbă. Este foarte important cum le proiectezi. (Ce, design URI? Trebuie să proiectez URI? Da, ar trebui să te gândești la asta). Proiectarea înseamnă, în mare parte, absența oricărei informații în URI.

Data creării documentului - data emiterii URI-ului - este ceva ce nu se va schimba niciodată. Este foarte utilă pentru a distinge cererile care folosesc noua sistemă de cele care folosesc vechea sistemă. Este un bun punct de plecare pentru URI. Dacă documentul are o dată, chiar și atunci când documentul va fi relevant în viitor, este un bun început.

Singura excepție este pagina care este intenționat considerată ‘ultima’ versiune, de exemplu, pentru întreaga organizație sau o mare parte din aceasta.

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

Aceasta este ultima coloană a Money Daily din revista Money. Principala rațiune pentru care această dată nu este necesară în acest URI este că nu există motive pentru a păstra un URI care va supraviețui revistei. Conceptul de Money Daily va dispărea atunci când Money va dispărea. Dacă dorești să te referi la conținut, ar trebui să te referi la el separat în arhive:

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

(Arată bine. Sugerează că 'money' va însemna același lucru pe parcursul întregii existențe a pathfinder.com. Există duplicare în '98' și un '.html' inutil, dar în rest arată ca un URI puternic.

Ce să lăsăm deoparte

Tot! În afară de data creării, punând orice informație în URI, te expui inevitabil la probleme.

Numele autorului. Autoria poate varia pe măsură ce apar versiuni noi. Oamenii părăsesc organizațiile și transferă lucrurile altora.
Subiect. Este foarte complicat. Arată bine la început, dar se schimbă surprinzător de repede. Voi detalia asta mai jos.
Stare. Cataloagele tip „vechi”, „ciornă” și așa mai departe, fără a menționa „ultimul” și „cool”, apar în toate sistemele de fișiere. Documentele își schimbă starea — altfel nu ar avea sens să creăm ciorne. Ultima versiune a documentului necesită un identificator constant, indiferent de starea sa. Mențineți starea în afara numelui.
Acces. La W3C am împărțit site-ul în secțiuni pentru angajați, membri și public. Asta sună bine, dar, desigur, documentele încep ca idei ale angajaților și sunt discutate cu membrii, apoi devin accesibile publicului. Este cu adevărat neplăcut dacă de fiecare dată când un document este deschis pentru o discuție mai largă, toate vechile linkuri către acesta se rup! Acum trecem la un cod simplu de dată.
Extensie de fișier. Un fenomen foarte comun. "cgi", chiar ".html" se vor schimba în viitor. Poate că peste 20 de ani nu veți mai folosi HTML pentru această pagină, dar linkurile de astăzi către ea ar trebui să funcționeze în continuare. Linkurile canonice de pe site-ul W3C nu folosesc extensia (cum se face).
Mecanisme de software. În URI caută "cgi", "exec" și altele care strigă „uitați-vă ce software folosim”. Cineva vrea să-și dedice întreaga viață scripturilor Perl CGI? Nu? Atunci elimină extensia .pl. Citește documentația serverului despre cum să faci asta.
Numele discului. Haide! Dar am văzut asta.

Așa că cel mai bun exemplu de pe site-ul nostru este pur și simplu

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

… raportul despre protocolul ședinței președinților W3C.

Teme și clasificare pe teme

Voi detalia mai mult despre acest pericol, deoarece este una dintre acele lucruri pe care cel mai greu le poți evita. De obicei, subiectele ajung în URI atunci când îți clasifici documentele în funcție de activitatea desfășurată. Însă această clasificare se va schimba în timp. Denumirile domeniilor se vor schimba. La W3C am dorit să schimbăm MarkUP în Markup, apoi în HTML, pentru a reflecta conținutul real al secțiunii. În plus, aici există adesea un spațiu de nume plat. După 100 de ani, ești sigur că nu vei dori să reutilizezi nimic? În viața noastră scurtă, am dorit deja să reutilizăm „Povestea” și „Tabelele de stiluri”, de exemplu.

Aceasta este o modalitate tentantă de organizare a unui site web - și într-adevăr o modalitate captivantă de organizare a oricăror lucruri, inclusiv a întregii Rețele. Este o soluție excelentă pe termen mediu, dar are dezavantaje serioase pe termen lung.

În parte, motivele rezidă în filosofia semnificației. Fiecare termen dintr-o limbă este un potențial obiect de clusterizare, iar fiecare persoană poate avea o viziune diferită asupra a ceea ce înseamnă. Deoarece relațiile dintre subiecte sunt mai degrabă asemănătoare unei pânze de păianjen decât unui copac, chiar și cei care sunt de acord cu pânza ar putea alege o altă reprezentare a copacului. Acestea sunt observațiile mele (adesea repetate) despre pericolele clasificării ierarhice ca soluție generală.

De fapt, atunci când folosești un nume de subiect în URI, te legi de o anumită clasificare. Este posibil să preferi o altă variantă în viitor. Atunci, URI-ul va fi supus unui conflict.

Motivul utilizării domeniului tematic ca parte a URI este că responsabilitatea pentru subsecțiunile spațiului URI este de obicei delegată, iar apoi ai nevoie de numele unei entități organizaționale - departament, grup sau altceva, care să fie responsabil pentru acest subspațiu. Aceasta este legătura URI cu structura organizațională. De obicei, este sigură doar atunci când, mai departe (la stânga) URI-ul este protejat de o dată: 1998/pics poate însemna pentru serverul tău „ceea ce aveam în vedere în 1998 sub pics”, nu „ceea ce am făcut în 1998 cu ceea ce acum numim pics”.

Nu uita numele de domeniu

Amintiți-vă că aceasta se referă nu doar la calea din URI, ci și la numele serverului. Dacă aveți servere separate pentru lucruri diferite, țineți cont că această separare nu va putea fi modificată fără a distruge multe, multe linkuri. Unele erori clasice, cum ar fi „uitați-vă ce software folosim astăzi” — numele de domeniu "cgi.pathfinder.com", "secure", "lists.w3.org". Acestea sunt create pentru a ușura administrarea serverelor. Indiferent dacă domeniul reprezintă o anumită divizie a companiei dumneavoastră, statutul documentului, nivelul de acces sau nivelul de securitate, fiți foarte, foarte atenți înainte de a folosi mai multe nume de domeniu pentru mai multe tipuri de documente. Amintiți-vă că puteți ascunde multiple servere web în interiorul unui singur server web vizibil, folosind redirecționarea și proxy-ing.

Da, și gândiți-vă și la numele dumneavoastră de domeniu. Nu vreți să fiți menționați ca soap.com după ce v-ați schimbat linia de produse și ați încetat să produceți săpun (Îmi cer scuze, celui care deține soap.com în acest moment).

Concluzie

Menținerea URI-urilor timp de 2, 20, 200 sau chiar 2000 de ani nu este, evident, atât de simplă cum pare. Cu toate acestea, în întreaga rețea, webmasterii iau decizii care își îngreunează cu adevărat această sarcină în viitor. De multe ori, acest lucru se întâmplă pentru că folosesc instrumente care trebuie să prezinte cel mai bun site doar în acel moment — și nimeni nu a evaluat ce se va întâmpla cu linkurile atunci când totul se va schimba. Totuși, ideea aici este că multe, foarte multe se pot schimba, iar URI-urile dumneavoastră pot și trebuie să rămână neschimbate. Acest lucru este posibil doar când vă gândiți la modul în care le creați.

Vezi de asemenea:

Tirada lui Jakob Nielsen pe aceeași temă

Adăugiri

Cum să eliminați extensiile de fișiere...

…din URI pe serverul web curent bazat pe fișiere?

Dacă folosiți, de exemplu, Apache, puteți să-l configurați pentru a adapta conținutul. Păstrați extensia fișierului (de exemplu, .png) în fișier (de exemplu, mydog.png), dar se poate face și fără el. Apoi, Apache verifică directorul pentru a găsi toate fișierele cu acest nume și orice extensie, putând alege cel mai bun dintre seturi (de exemplu, GIF și PNG). Și nu este nevoie să plasați diferite tipuri de fișiere în directoare diferite, de fapt, corelarea conținutului nu va funcționa dacă faceți așa.

Configurați serverul pentru a corela conținutul
Faceți întotdeauna referiri la URI fără extensie

Referirile cu extensii vor funcționa în continuare, dar nu vor permite serverului dumneavoastră să aleagă cel mai bun dintre formatele disponibile acum și în viitor.

(De fapt, câinele meu, mydog.png și mydog.gif — resurse web valide, câinele meu — este o resursă de tip conținut universal, iar mydog.png și mydog.gif — resurse de tip conținut specific).

Desigur, dacă scrieți propriul server web, ar fi bine să folosiți o bază de date pentru a lega identificatorii permanenți de forma lor actuală, deși fiți atenți la creșterea nelimitată a Bazei de Date.

Tabloul rușinii — Povestea 1: Channel 7

În cursul anului 1999, am urmărit închiderea școlilor din cauza zăpezii pe pagina http://www.whdh.com/stormforce/closings.shtml. Nu era de așteptat să aștept informația să apară în partea de jos a ecranului televizorului! Am pus un link pe pagina mea de start. Vine prima mare furtună de zăpadă din anul 2000 și verific pagina. Scria:

— La data de.
În prezent, nimic nu este închis. Vă rugăm să reveniți în cazul avertismentelor meteorologice.

Nu poate fi, o furtună atât de puternică. E amuzant că data lipsește. Dar dacă accesați pagina principală a site-ului, acolo va fi un buton mare „Școlile închise”, care duce la o pagină http://www.whdh.com/stormforce/ cu o listă lungă de școli închise.

Poate că au schimbat sistemul de obținere a listei — dar nu era nevoie să schimbe URI.

Tabloul rușinii — Povestea 2: Microsoft Netmeeting

Cu dependența în creștere de internet, a apărut ideea că aplicațiile pot încorpora linkuri către site-ul producătorului. Acest lucru a fost folosit frecvent și abuziv, dar — nu se poate schimba URL-ul. Chiar zilele trecute am încercat un link din clientul Microsoft Netmeeting 2/something în meniul Ajutor/Microsoft pe Web/Chestii gratuite și am primit eroarea 404 — serverul nu a găsit răspuns. Poate a fost reparat deja...

Notă istorică: la sfârșitul secolului XX, când a fost scrisă aceasta, „cool” era un epitete de aprobat, mai ales printre tineri, indicând popularitate, calitate sau relevanță. În grabă, calea URI era adesea aleasă din „coolness”, nu din utilitate sau durabilitate. Această notă este o încercare de a redirecționa energia în spatele căutării coolness-ului.

Sursa: habr.com