Autor: Sir Tim Berners-Lee, inventator al URI-urilor, URL-urilor, HTTP, HTML și World Wide Web și actual șef al W3C. Articol scris în 1998

Ce URI este considerat „cool”?
Una care nu se schimbă.
Cum se schimbă URI-urile?
URI-urile nu se schimbă: oamenii le schimbă.

În teorie, nu există niciun motiv pentru ca oamenii să schimbe URI-urile (sau să oprească documentele justificative), dar în practică există milioane de ele.

În teorie, proprietarul nominal al unui spațiu de nume de domeniu deține de fapt spațiul de nume de domeniu și, prin urmare, toate URI-urile din acesta. În afară de insolvență, nimic nu îl împiedică pe proprietarul unui nume de domeniu să păstreze numele. Și, teoretic, spațiul URI de sub numele dvs. de domeniu este în întregime sub controlul dvs., așa că îl puteți face cât de stabil doriți. Aproape, singurul motiv bun pentru ca un document să dispară de pe internet este că compania care deținea numele domeniului a încetat să funcționeze sau nu își mai permite să mențină serverul în funcțiune. Atunci de ce există atât de multe verigi lipsă în lume? Unele dintre acestea sunt pur și simplu o lipsă de gândire. Iată câteva motive pentru care ați putea auzi:

Tocmai am reorganizat site-ul pentru a-l îmbunătăți.

Chiar crezi că vechile URI-uri nu mai pot funcționa? Dacă da, atunci i-ai ales foarte prost. Luați în considerare păstrarea celor noi pentru următoarea reproiectare.

Avem atât de multe lucruri încât nu putem ține evidența a ceea ce este învechit, a ceea ce este confidențial și a ceea ce este încă relevant, așa că ne-am gândit că este mai bine să o dezactivăm pe toate.

Nu pot decât să simpatizez. W3C a trecut printr-o perioadă în care a trebuit să cercetăm cu atenție materialele de arhivă pentru confidențialitate înainte de a le face publice. Decizia ar trebui gândită în avans - asigurați-vă că cu fiecare document înregistrați cititorii acceptabili, data creării și, în mod ideal, data de expirare. Salvați aceste metadate.

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

Aceasta este una dintre cele mai jalnice scuze. Mulți oameni nu știu că serverele web vă permit să controlați relația dintre URI-ul unui obiect și locația sa reală în sistemul de fișiere. Gândiți-vă la spațiul URI ca la un spațiu abstract, perfect organizat. Apoi faceți o mapare cu orice realitate pe care o folosiți pentru a o realiza. Apoi raportați acest lucru serverului web. Puteți chiar să scrieți propriul fragment de server pentru a le face corect.

John nu mai menține acest fișier, Jane acum o face.

Numele lui John era în URI? Nu, fișierul era doar în directorul lui? Ei bine, bine.

Anterior am folosit un script CGI pentru asta, dar acum folosim un program binar.

Există o idee nebună că paginile create de scripturi ar trebui să fie situate în zona „cgibin” sau „cgi”. Acest lucru expune mecanica modului în care rulați serverul dvs. web. Schimbați mecanismul (chiar și în timp ce salvați conținut) și hopa - toate URI-urile dvs. se schimbă.

Luați, de exemplu, Fundația Națională pentru Știință (NSF):

Documente online NSF

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

Prima pagină care începe să vizualizeze documentele nu va rămâne în mod evident aceeași în câțiva ani. cgi-bin, oldbrowse и pl - toate acestea oferă informații despre cum-o-o-o-o facem-acum. Dacă utilizați pagina pentru a căuta un document, primul rezultat pe care îl obțineți este la fel de rău:

Raport al Grupului de Lucru pentru Criptologie și Teoria Codării

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

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

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

Aici antetul pubs/1998 va oferi oricărui serviciu de arhivă viitor un indiciu bun că vechea schemă de clasificare a documentelor din 1998 este în vigoare. Deși numerele documentelor pot arăta diferit în 2098, mi-aș imagina că acest URI va fi în continuare valabil și nu ar interfera cu NSF sau cu orice altă organizație care ar menține arhiva.

Nu credeam că URL-urile trebuie să fie persistente - existau URN-uri.

Acesta este probabil unul dintre cele mai grave efecte secundare ale dezbaterii URN. Unii oameni cred că, din cauza cercetării asupra unui spațiu de nume mai permanent, ar putea fi neglijenți în privința legăturilor suspendate, deoarece „URN-urile vor rezolva toate acestea”. Dacă ești unul dintre acești oameni, atunci lasă-mă să te dezamăgesc.

Cele mai multe scheme URN pe care le-am văzut arată ca un identificator de autoritate urmat fie de o dată și de un șir pe care îl selectați, fie doar de un șir pe care îl selectați. Acesta este foarte asemănător cu un URI HTTP. Cu alte cuvinte, dacă credeți că organizația dvs. va fi capabilă să creeze URN-uri de lungă durată, atunci dovediți acest lucru acum utilizându-le pentru URI-urile dvs. HTTP. Nu există nimic în HTTP în sine care să vă facă URI-ul instabil. Doar organizația dvs. Creați o bază de date care mapează documentul URN cu numele de fișier curent și lăsați serverul web să o folosească pentru a prelua efectiv fișierele.

Dacă ați ajuns în acest punct, dacă nu aveți timp, bani și conexiuni pentru a dezvolta un software, atunci puteți declara următoarea scuză:

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

Dar poți simpatiza cu asta. Sunt complet de acord. Ceea ce trebuie să faceți este să forțați serverul web să analizeze instantaneu URI-ul persistent și să returneze fișierul oriunde este stocat în prezent în sistemul dvs. de fișiere nebun. Doriți să stocați toate URI-urile într-un fișier ca verificare și să păstrați baza de date actualizată în orice moment. Doriți să păstrați relația dintre diferite versiuni și traduceri ale aceluiași document și, de asemenea, să mențineți o înregistrare independentă a sumei de control pentru a vă asigura că fișierul nu este corupt de o eroare accidentală. Și serverele web pur și simplu nu ies din cutie cu aceste caracteristici. Când doriți să creați un document nou, editorul vă solicită să specificați un URI.

Trebuie să puteți schimba proprietatea, accesul la documente, securitatea la nivel de arhivă etc. în spațiul URI fără a schimba URI.

E prea rău. Dar vom corecta situația. La W3C, folosim funcționalitatea Jigedit (server de editare Jigsaw) care urmărește versiunile și experimentăm cu scripturi de generare a documentelor. Dacă dezvoltați instrumente, servere și clienți, acordați atenție acestei probleme!

Această scuză se aplică și pentru multe pagini W3C, inclusiv pentru aceasta: deci fă cum spun eu, nu așa cum fac eu.

De ce mi-ar păsa?

Când schimbați URI-ul pe serverul dvs., nu puteți spune complet cine va avea link-uri către vechiul URI. Acestea pot fi link-uri de la pagini web obișnuite. Marcați pagina dvs. Este posibil ca URI-ul să fi fost mâzgălit în marginile unei scrisori către un prieten.

Când cineva urmărește un link și acesta este întrerupt, de obicei își pierde încrederea în proprietarul serverului. De asemenea, este frustrat, atât emoțional, cât și fizic, de faptul că nu își poate atinge scopul.

Mulți oameni se plâng de legături rupte tot timpul și sper că daunele sunt evidente. Sper că prejudiciul reputației adus întreținătorului serverului unde a dispărut documentul este, de asemenea, evident.

Si ce ar trebui sa fac? Design URI

Este responsabilitatea webmasterului să aloce URI-uri care pot fi folosite în 2 ani, în 20 de ani, în 200 de ani. Acest lucru necesită atenție, organizare și determinare.

URI-urile se modifică dacă se modifică orice informație din ele. Modul în care le proiectați este foarte important. (Ce, design URI? Trebuie să proiectez URI? Da, ar trebui să vă gândiți la asta). Designul înseamnă practic să omiteți orice informație din URI.

Data la care a fost creat documentul - data la care a fost emis URI - este ceva care nu se va schimba niciodată. Este foarte util pentru a separa interogările care folosesc noul sistem de cele care folosesc sistemul vechi. Acesta este un loc bun pentru a începe cu un URI. Dacă un document este datat, chiar dacă documentul va fi relevant în viitor, atunci acesta este un început bun.

Singura excepție este o pagină care este în mod intenționat cea mai recentă versiune, de exemplu pentru întreaga organizație sau o mare parte a acesteia.

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

Aceasta este cea mai recentă rubrică Money Daily din revista Money. Motivul principal pentru care nu este nevoie de o dată în acest URI este că nu există niciun motiv pentru a stoca URI-ul care va supraviețui jurnalului. Conceptul de Money Daily va dispărea când Money va dispărea. Dacă doriți să creați un link către conținut, ar trebui să faceți un link către acesta separat în arhive:

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

(Arata bine. Presupune că „bani” vor însemna același lucru pe toată durata de viață a pathfinder.com. Există un „98” duplicat și un „.html” inutil, dar în rest arată ca un URI puternic.

Ce să lași deoparte

Toate! În afară de data creării, introducerea oricărei informații în URI înseamnă probleme într-un fel sau altul.

Numele autorului. Calitatea de autor se poate modifica pe măsură ce noi versiuni devin disponibile. Oamenii părăsesc organizațiile și transmit lucruri altora.
subiect. Este foarte dificil. La început arată întotdeauna bine, dar se schimbă surprinzător de repede. Voi vorbi mai multe despre asta mai jos.
Stare. În toate sistemele de fișiere apar directoare precum „vechi”, „schiță” și așa mai departe, ca să nu mai vorbim de „latest” și „cool”. Documentele își schimbă statutul - altfel nu ar avea rost să creăm schițe. Cea mai recentă versiune a unui document are nevoie de un identificator persistent, indiferent de starea acestuia. Păstrați statutul în afara numelui.
Acces. La W3C, am împărțit site-ul în secțiuni pentru angajați, membri și public. Acest lucru sună bine, dar, desigur, documentele încep ca idei de echipă din partea personalului, sunt discutate cu membrii și apoi devin cunoscute publicului. Ar fi într-adevăr păcat dacă de fiecare dată când un document este deschis pentru o discuție mai largă, toate legăturile vechi către acesta sunt rupte! Acum trecem la un cod de dată simplu.
Extensie de fișier. Un fenomen foarte des întâlnit. „cgi”, chiar și „.html” se vor schimba în viitor. Este posibil să nu mai utilizați HTML pentru această pagină în 20 de ani, dar linkurile de astăzi către aceasta ar trebui să funcționeze în continuare. Linkurile canonice de pe site-ul W3C nu folosesc extensia (cum se face).
Mecanisme software. În URI, căutați „cgi”, „exec” și alți termeni care strigă „uită-te la ce software folosim”. Dorește cineva să-și petreacă întreaga viață scriind scripturi Perl CGI? Nu? Apoi eliminați extensia .pl. Citiți manualul serverului despre cum să faceți acest lucru.
Numele discului. Haide! Dar am văzut asta.

Deci cel mai bun exemplu de pe site-ul nostru este pur și simplu

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

... raport asupra procesului-verbal al reuniunii președinților W3C.

Subiecte și clasificare pe teme

Voi intra în mai multe detalii despre acest pericol, deoarece este unul dintre acele lucruri care este cel mai greu de evitat. În mod obișnuit, subiectele ajung în URI atunci când îți clasificați documentele în funcție de munca pe care o fac. Dar această defalcare se va schimba în timp. Numele zonelor se vor schimba. La W3C am vrut să schimbăm MarkUP la Markup și apoi la HTML pentru a reflecta conținutul real al secțiunii. În plus, există adesea un spațiu de nume plat. Peste 100 de ani, ești sigur că nu vei dori să refolosești nimic? În scurta noastră viață, ne-am dorit deja să reutilizam „Istorie” și „Foaie de stil”, de exemplu.

Este o modalitate tentantă de a organiza un site web și o modalitate cu adevărat tentantă de a organiza orice, inclusiv întregul Web. Aceasta este o soluție excelentă pe termen mediu, dar are deficiențe serioase pe termen lung.

O parte a motivului constă în filosofia sensului. Fiecare termen dintr-o limbă este o țintă potențială pentru grupare și fiecare persoană poate avea o idee diferită despre ceea ce înseamnă. Deoarece relațiile dintre entități seamănă mai mult cu un web decât cu un arbore, chiar și cei care sunt de acord cu web-ul pot alege o reprezentare diferită a arborelui. Acestea sunt observațiile mele generale (deseori repetate) despre pericolele clasificării ierarhice ca soluție generală.

De fapt, atunci când folosești un nume de subiect într-un URI, te angajezi la un fel de clasificare. Poate că în viitor vei prefera o altă opțiune. URI-ul va fi apoi susceptibil de încălcare.

Motivul pentru care se utilizează un domeniu ca parte a unui URI este că responsabilitatea pentru subsecțiunile spațiului URI este de obicei delegată, iar apoi aveți nevoie de numele organismului organizațional - departament, grup sau orice altceva - care este responsabil pentru acel subspațiu. Acesta este un URI care se leagă de o structură organizațională. De obicei, este sigur numai dacă URI-ul mai departe (stânga) este protejat de o dată: 1998/pics ar putea însemna pentru serverul dvs. „ceea ce am vrut să spunem în 1998 cu poze” mai degrabă decât „ce am făcut în 1998 cu ceea ce numim acum imagini”.

Nu uitați numele domeniului

Rețineți că acest lucru se aplică nu numai căii din URI, ci și numelui serverului. Dacă aveți servere separate pentru lucruri diferite, amintiți-vă că această diviziune va fi imposibil de schimbat fără a distruge multe, multe link-uri. Unele greșeli clasice „uitați-vă la software-ul pe care îl folosim astăzi” sunt numele de domenii „cgi.pathfinder.com”, „secure”, „lists.w3.org”. Sunt concepute pentru a facilita administrarea serverului. Indiferent dacă un domeniu reprezintă o divizie în compania dvs., o stare de document, un nivel de acces sau un nivel de securitate, fiți foarte, foarte atenți înainte de a utiliza mai mult de un nume de domeniu pentru mai multe tipuri de documente. Rețineți că puteți ascunde mai multe servere web într-un singur server web vizibil folosind redirecționarea și proxy.

Oh, și gândește-te și la numele tău de domeniu. Nu doriți să fiți denumit soap.com după ce schimbați liniile de produse și nu mai faceți săpun (Ne pare rău celor care dețin soap.com în acest moment).

Concluzie

Păstrarea unui URI timp de 2, 20, 200 sau chiar 2000 de ani, evident, nu este atât de ușoară pe cât pare. Cu toate acestea, pe tot Internetul, webmasterii iau decizii care fac această sarcină cu adevărat dificilă pentru ei înșiși în viitor. Adesea acest lucru se datorează faptului că folosesc instrumente a căror sarcină este să prezinte cel mai bun site doar în acest moment - și nimeni nu a evaluat ce se va întâmpla cu link-urile când totul se va schimba. Cu toate acestea, ideea aici este că multe, multe lucruri se pot schimba, iar URI-urile dvs. pot și ar trebui să rămână aceleași. Acest lucru este posibil doar atunci când vă gândiți la modul în care le creați.

Vezi și:

Tirada lui Jakob Nielsen pe aceeași temă

Suplimente

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

...de la un URI din serverul web actual bazat pe fișiere?

Dacă utilizați Apache, de exemplu, îl puteți configura pentru a negocia conținut. Salvați extensia fișierului (de ex. .png) într-un fișier (de ex. câinele meu.png), dar vă puteți conecta la o resursă web fără aceasta. Apache verifică apoi directorul pentru toate fișierele cu acest nume și orice extensie și îl poate alege pe cel mai bun din set (de exemplu, GIF și PNG). Și nu este nevoie să puneți diferite tipuri de fișiere în directoare diferite, de fapt potrivirea conținutului nu va funcționa dacă faceți asta.

Configurați-vă serverul pentru a negocia conținut
Conectați întotdeauna la URI-uri fără extensie

Linkurile cu extensii vor funcționa în continuare, dar vor împiedica serverul dvs. să aleagă cel mai bun format disponibil în prezent și în viitor.

(De fapt, mydog, mydog.png и mydog.gif — resurse web valide, mydog este o resursă universală de tip conținut și mydog.png и mydog.gif — resurse de un anumit tip de conținut).

Desigur, dacă vă scrieți propriul server web, este o idee bună să utilizați o bază de date pentru a lega identificatorii persistenti la forma lor actuală, deși aveți grijă de creșterea nelimitată a bazei de date.

Board of Shame - Povestea 1: Canalul 7

În 1999, am urmărit pe pagină închiderile școlilor din cauza zăpezii http://www.whdh.com/stormforce/closings.shtml. Nu așteptați ca informațiile să apară în partea de jos a ecranului televizorului! Am făcut link la el de pe pagina mea de pornire. Vine prima furtună mare de zăpadă din 2000 și verific pagina. Este scris acolo:,

- Începând cu.
Nimic nu este închis momentan. Vă rugăm să reveniți în caz de avertismente meteo.

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

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

Board of Shame - Povestea 2: Microsoft Netmeeting

Odată cu dependența tot mai mare de internet, a venit o idee inteligentă că link-urile către site-ul web al producătorului ar putea fi încorporate în aplicații. Acesta a fost folosit și abuzat foarte mult, dar nu puteți schimba adresa URL. Chiar zilele trecute am încercat un link de la Microsoft Netmeeting 2/client ceva în meniul Ajutor/Microsoft pe Web/Lucruri gratuite și am primit o eroare 404 - nu a fost găsit niciun răspuns de la server. Poate s-a rezolvat deja...

Notă istorică: La sfârșitul secolului al XX-lea, când a fost scris acest lucru, „cool” era un epitet de aprobare, în special în rândul tinerilor, indicând modă, calitate sau adecvare. În grabă, calea URI a fost adesea aleasă pentru „cool” mai degrabă decât pentru utilitate sau durabilitate. Această postare este o încercare de a redirecționa energia din spatele căutării cool.

Sursa: www.habr.com

URI-urile cool nu se schimbă