Autore: Sir Tim Berners-Lee, inventore di URI, URL, HTTP, HTML e del World Wide Web, attuale presidente del W3C. Articolo scritto nel 1998

Quale URI può essere considerato "cool"?
Quello che non cambia.
Come cambiano gli URI?
Gli URI non cambiano: li cambiano gli esseri umani.

In teoria, non ci sono motivi per cui le persone dovrebbero cambiare gli URI (o smettere di mantenere i documenti), ma nella pratica ce ne sono milioni.

Teoricamente, il proprietario nominale dello spazio dei nomi di dominio possiede effettivamente lo spazio dei nomi di dominio e, quindi, tutti gli URI in esso. A meno che non si trovi in difficoltà finanziarie, nulla impedisce al proprietario del dominio di mantenere quel nome. E teoricamente, lo spazio URI sotto il tuo dominio è completamente sotto il tuo controllo, quindi puoi renderlo stabile quanto vuoi. Fondamentalmente, l'unica ragione valida per cui un documento scompare da Internet è che l'azienda proprietaria del dominio è andata fuori mercato o non può più permettersi di mantenere il server. Allora, perché ci sono così tanti link rotti nel mondo? In parte è semplicemente una mancanza di previsione. Ecco alcune ragioni che si possono sentire:

Abbiamo semplicemente riorganizzato il sito per renderlo migliore.

Davvero pensi che i vecchi URI non possano più funzionare? Se è così, li hai scelti molto male. Pensa a far sì che i nuovi resistano anche dopo il prossimo restyling.

Abbiamo così tanto materiale che non riusciamo a tenere il passo con ciò che è obsoleto, ciò che è riservato e ciò che è ancora pertinente, e quindi abbiamo pensato che fosse meglio semplicemente disattivare tutto.

Posso solo sympathizzare. Il W3C ha attraversato un periodo in cui dovevamo setacciare attentamente i materiali archiviati per questioni di privacy prima di renderli pubblici. La decisione deve essere ben pensata in anticipo: assicurati di segnalare con ogni documento un pubblico accettabile, la data di creazione e, idealmente, una scadenza. Conserva questi metadati.

Bene, abbiamo scoperto che dovevamo spostare i file…

Questa è una delle scuse più miserevoli. Molti non sanno che i server web ti consentono di gestire il collegamento tra l'URI di un oggetto e la sua reale ubicazione nel filesystem. Immagina lo spazio URI come uno spazio astratto, perfettamente organizzato. Poi fai una mappatura su qualsiasi realtà che stai effettivamente utilizzando per implementarla. Infine, comunica questo al server web. Puoi persino scrivere un frammento del tuo server per farlo correttamente.

John non supporta più questo file, ora lo fa Jane.

Il nome di John era nell'URI? No, semplicemente il file si trovava nella sua directory? Capisco.

In passato usavamo uno script CGI per farlo, ora usiamo un programma binario.

Esiste un'idea folle secondo cui le pagine generate da script dovrebbero trovarsi nell'area "cgibin" o "cgi". Questo rivela il meccanismo di come esegui il tuo server web. Cambia il meccanismo (anche mantenendo il contenuto) ed ecco—tutti i tuoi URI cambiano.

Prendiamo ad esempio il National Science Foundation (NSF):

Documenti online NSF

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

La prima pagina per iniziare a visualizzare i documenti chiaramente non rimarrà tale dopo alcuni anni. cgi-bin, oldbrowse e pl — tutto ciò fornisce frammenti di informazioni su come-stiamo-facendo-questo-ora. Se invece utilizzi una pagina per cercare un documento, ottieni inizialmente un risultato altrettanto scarso:

Rapporto del gruppo di lavoro sulla crittografia e sulla teoria dei codici

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

per la pagina indice del documento, anche se il documento html stesso appare molto meglio:

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

Qui il titolo pubs/1998 offre a qualsiasi futuro servizio di archiviazione una buona chiave per comprendere che opera il vecchio schema di classificazione dei documenti del 1998. Anche se nel 2098 i numeri dei documenti potrebbero apparire diversi, posso immaginare che questo URI sarà ancora valido, e non ostacolerà NSF o qualsiasi altra organizzazione che gestirà l'archivio.

Non pensavo che gli URL dovessero essere permanenti—ci sono stati URN.

Probabilmente è uno dei peggiori effetti collaterali della discussione sugli URN. Alcuni pensano che a causa della ricerca su uno spazio dei nomi più permanente possano trattare con superficialità i link interrotti, poiché "URN sistemerà tutto questo". Se sei una di queste persone, permettimi di deluderti.

La maggior parte degli schemi URN che ho visto somigliano a un identificatore di autorità, seguito da una data e da una stringa a scelta, oppure semplicemente dalla stringa che scegli. È molto simile a un URI HTTP. In altre parole, se pensi che la tua organizzazione sarà in grado di creare URN durature, dimostralo ora utilizzandole per i tuoi URI HTTP. Non c'è nulla di instabile nel tuo URI all'interno dell'HTTP. Solo la tua organizzazione. Crea un database che mappa l'URN del documento con l'attuale nome del file e permetti al server web di usarlo per l'effettivo recupero dei file.

Se sei arrivato a questo punto, se non hai tempo, denaro e contatti per sviluppare un software, puoi elencare la seguente giustificazione:

Volevamo farlo, ma non abbiamo gli strumenti necessari.

E questo è comprensibile. Sono completamente d'accordo. Quello che devi fare è far sì che il server web gestisca immediatamente l'URI permanente e restituisca il file, ovunque esso si trovi attualmente nel tuo attuale e caotico sistema di file. Vuoi conservare tutti gli URI in un file come verifica e mantenere costantemente aggiornato il database. Vuoi mantenere le relazioni tra le varie versioni e traduzioni dello stesso documento e conservare un registro indipendente del checksum per proteggerti dalla corruzione del file causata da errori casuali. E i server web non vengono forniti con queste funzionalità. Quando vuoi creare un nuovo documento, il tuo editor ti chiede di assegnare un URI.

Hai bisogno della possibilità di modificare la proprietà, l'accesso al documento, il livello di sicurezza del livello archivistico e altro ancora nello spazio URI senza cambiare l'URI.

È tutto estremamente negativo. Ma sistemeremo la situazione. In W3C utilizziamo la funzionalità Jigedit (server Jigsaw per la modifica), che tiene traccia delle versioni, e stiamo sperimentando con script per la creazione di documenti. Se stai sviluppando strumenti, server e client, presta attenzione a questo problema!

Questa giustificazione si applica anche a molte pagine del W3C, inclusa questa: quindi fai ciò che dico, non ciò che faccio.

Perché dovrei preoccuparmene?

Quando cambi il URI sul tuo server, non puoi mai sapere con certezza chi avrà collegamenti al vecchio URI. Possono provenire da pagine web comuni. I segnalibri alla tua pagina. Il URI potrebbe essere stato scritto a mano nei margini di una lettera a un amico.

Quando qualcuno clicca su un link e questo è rotto, di solito perde fiducia nel proprietario del server. È anche deluso, sia emotivamente che realmente, dalla impossibilità di raggiungere il suo obiettivo.

Molte persone si lamentano costantemente dei link rotti e spero che il danno sia evidente. Spero che sia evidente anche il danno alla reputazione del manutentore del server dove il documento è scomparso.

Cosa devo fare? Progettare l'URI.

È compito del webmaster creare URI che possano essere utilizzati tra 2 anni, 20 anni, 200 anni. Ci vogliono ponderatezza, organizzazione e determinazione.

Le URI cambiano se cambia qualche informazione in esse. È molto importante come le progetti. (Cosa, progettare un URI? Devo progettare un URI? Sì, dovresti pensarci). Progettare significa principalmente garantire l'assenza di informazioni in un URI.

La data di creazione del documento — la data di emissione del URI — è qualcosa che non cambierà mai. È molto utile per separare le richieste che utilizzano un nuovo sistema da quelle che utilizzano un vecchio sistema. È un buon punto di partenza per il URI. Se un documento ha una data, anche se rimarrà pertinente in futuro, è un buon inizio.

L'unica eccezione è la pagina che è intenzionalmente l'ultima versione, per esempio, per tutta l'organizzazione o gran parte di essa.

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

Questa è l'ultima colonna di Money Daily nella rivista Money. La ragione principale per cui questo URI non ha bisogno di una data è che non ci sono motivi per preservare un URI che sopravvivrà alla rivista. Il concetto di Money Daily scomparirà quando scomparirà Money. Se vuoi fare riferimento ai contenuti, dovresti farlo separatamente negli archivi:

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

(Sembra buono. Presuppone che "money" significherà sempre la stessa cosa per tutta la durata di pathfinder.com. C'è una duplicazione di "98" e un inutile ".html", ma per il resto sembra un URI forte.

Cosa lasciare da parte

Tutto! A parte la data di creazione, mettendo qualsiasi informazione in un URI, in un modo o nell'altro, ti stai attirando dei guai.

Nome dell'autore. La paternità può cambiare con l'uscita di nuove versioni. Le persone lasciano le organizzazioni e trasferiscono le cose ad altri.
Oggetto. È molto complicato. Sembra sempre buono all'inizio, ma cambia sorprendentemente in fretta. Ne parlerò più in dettaglio qui sotto.
Stato. Cataloghi come "vecchio", "bozza" e così via, per non parlare di "ultimo" e "cool", compaiono in tutti i sistemi di file. I documenti cambiano stato — altrimenti non avrebbe senso creare bozze. L'ultima versione di un documento ha bisogno di un identificatore costante, indipendentemente dal suo stato. Mantieni lo stato al di fuori del nome.
Accesso. In W3C abbiamo diviso il sito in sezioni per dipendenti, membri e pubblico. Suona bene, ma naturalmente i documenti partono come idee di gruppo dei dipendenti, vengono discussi con i membri e poi diventano di pubblico dominio. È davvero deludente se ogni volta che un documento viene aperto per una discussione più ampia, tutti i vecchi link su di esso si rompono! Ora passiamo a un semplice codice di data.
Estensione del file. È un fenomeno molto comune. "cgi", anche ".html" cambieranno in futuro. Potrebbe essere che tra 20 anni non userai più HTML per questa pagina, ma i link di oggi devono ancora funzionare. I link canonici sul sito W3C non usano l'estensione (come si fa).
Meccanismi software. In URI cerca "cgi", "exec" e altri termini che gridano «guarda quale software stiamo usando». Qualcuno vuole dedicare tutta la vita agli script Perl CGI? No? Allora elimina l'estensione .pl. Leggi il manuale del server su come farlo.
Nome del disco. Dai! Ma io l'ho visto.

Quindi, il miglior esempio dal nostro sito è semplicemente

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

… il rapporto del protocollo delle riunioni dei presidenti W3C.

Temi e classificazione per argomenti

Parlerò più dettagliatamente di questo pericolo, poiché è una delle cose più difficili da evitare. In generale, i temi finiscono negli URI quando classifichi i tuoi documenti in base al lavoro svolto. Ma questa suddivisione cambierà nel tempo. I nomi delle aree cambieranno. In W3C volevamo cambiare MarkUP in Markup e poi in HTML per riflettere il contenuto reale della sezione. Inoltre, qui spesso ci sono nomi di spazio piatti. Tra 100 anni, sei sicuro di non voler riutilizzare nulla? Nella nostra breve vita abbiamo già voluto riutilizzare 'Storia' e 'Fogli di stile', per esempio.

È un modo allettante di organizzare un sito web — e davvero un modo attraente di organizzare qualsiasi cosa, inclusa l'intera rete. È una buona soluzione a medio termine, ma presenta seri svantaggi a lungo termine.

In parte le ragioni risiedono nella filosofia del significato. Ogni termine in una lingua è un potenziale oggetto di clustering, e ogni persona può avere una visione diversa di ciò che significa. Poiché le relazioni tra gli oggetti somigliano più a una rete che a un albero, anche coloro che concordano sulla rete potrebbero scegliere una rappresentazione dell'albero diversa. Questi sono i miei (spesso ripetuti) commenti generali sui pericoli della classificazione gerarchica come soluzione generale.

In effetti, quando usi un nome tema in un URI, ti vincoli a una certa classificazione. Potresti preferire un'altra opzione in futuro. Allora l'URI sarà soggetto a violazione.

La ragione per cui si utilizza un'area tematica come parte di un URI è che la responsabilità per le sottomissioni dello spazio URI è solitamente delegata, e quindi hai bisogno del nome dell'organo organizzativo — divisione, gruppo o altro — che è responsabile di quello sottospazio. Questo vincola l'URI alla struttura organizzativa. Di solito è sicura solo quando più avanti (a sinistra) l'URI è protetto da una data: 1998/pics potrebbe significare per il tuo server 'ciò che intendevamo nel 1998 con pics', e non 'ciò che nel 1998 abbiamo fatto con ciò che ora chiamiamo pics'.

Non dimenticare il nome di dominio

Ricorda che questo si applica non solo al percorso nell'URI, ma anche al nome del server. Se hai server separati per cose diverse, ricorda che questa suddivisione sarà impossibile da modificare senza distruggere molti, molti link. Alcuni errori classici come 'guarda quale software stiamo usando oggi' – nomi di dominio "cgi.pathfinder.com", "secure", "lists.w3.org". Sono stati creati per facilitare l'amministrazione dei server. Indipendentemente dal fatto che il dominio rappresenti una qualche divisione della tua azienda, lo stato del documento, il livello di accesso o il livello di sicurezza, fai molta, molta attenzione prima di utilizzare più di un nome di dominio per diversi tipi di documenti. Ricorda che puoi nascondere molti server web all'interno di un unico server web visibile utilizzando il reindirizzamento e il proxy.

Sì, e pensa anche al tuo nome di dominio. Non vuoi essere citato come soap.com dopo aver cambiato la tua gamma di prodotti e smesso di produrre sapone (mi scuso con chi possiede soap.com in questo momento).

Conclusione

Mantenere l'URI per 2, 20, 200 o anche 2000 anni non è ovviamente così semplice come sembra. Tuttavia, su tutta la rete, i webmaster prendono decisioni che complicano davvero questo compito in futuro. Spesso ciò accade perché utilizzano strumenti il cui obiettivo è quello di presentare il miglior sito possibile solo in quel momento - e nessuno ha valutato cosa accadrà ai link quando tutto cambierà. Tuttavia, il punto è che molto, molto può cambiare e i tuoi URI possono e devono rimanere gli stessi. Questo è possibile solo se pensi a come li crei.

Vedi anche:

Il rant di Jakob Nielsen sullo stesso argomento

Integrazioni

Come rimuovere le estensioni dei file…

…dall'URI nel server web attuale basato su file?

Se utilizzi, ad esempio, Apache, puoi configurarlo per concordare il contenuto. Mantieni l'estensione del file (ad esempio, .png) nel file (ad esempio, mydog.png), ma è possibile fare riferimento a una risorsa web anche senza di essa. Successivamente, Apache controlla la directory per la presenza di tutti i file con questo nome e qualsiasi estensione, e può anche scegliere il migliore di un insieme (ad esempio, GIF e PNG). E non è necessario collocare diversi tipi di file in directory diverse, in realtà la negazione del contenuto non funzionerà se si fa questo.

Configura il tuo server per la negazione del contenuto
Fai sempre riferimento a URI senza estensione

I link con estensioni funzioneranno ancora, ma non permetteranno al tuo server di scegliere il migliore dei formati attualmente disponibili e futuri.

(In realtà, mydog, mydog.png e mydog.gif — sono risorse web valide, mydog — è una risorsa di tipo contenuto universale, e mydog.png e mydog.gif — risorse di un tipo di contenuto specifico).

Certo, se stai scrivendo il tuo server web, è utile utilizzare un database per associare identificatori permanenti alla loro forma attuale, anche se fai attenzione alla crescita illimitata della BDD.

La bacheca degli orrori — Storia 1: Channel 7

Nel 1999 ho monitorato la chiusura delle scuole a causa della neve sulla pagina http://www.whdh.com/stormforce/closings.shtml. Non posso aspettare che le informazioni appaiano in fondo allo schermo della televisione! Ho messo un link sulla mia homepage. Arriva la prima grande tempesta di neve del 2000 e controlla la pagina. È scritto:

— Aggiorniamo a.
Attualmente non ci sono chiusure. Si prega di tornare in caso di avvisi meteorologici.

Non può essere, una tempesta così forte. È divertente che la data sia assente. Ma se si torna alla homepage del sito, c'è un grande pulsante "Scuole chiuse" che porta a una pagina http://www.whdh.com/stormforce/ con un lungo elenco di scuole chiuse.

Forse hanno cambiato il sistema per ottenere l'elenco — ma non dovevano cambiare l'URI.

La bacheca degli orrori — Storia 2: Microsoft Netmeeting

Con la crescente dipendenza da Internet è emersa l'idea intelligente di incorporare link ai siti dei produttori nelle applicazioni. Questo è stato spesso fatto e abusato, ma — non è possibile modificare l'URL. Di recente ho provato un link dal client Microsoft Netmeeting 2/something nel menu Help/Microsoft sul web/Cose gratuite e ho ricevuto un errore 404 – risposta non trovata dal server. Forse già sistemato…

Nota storica: alla fine del XX secolo, quando è stato scritto questo testo, "figo" era un epiteto di approvazione, soprattutto tra i giovani, che indicava moda, qualità o pertinenza. Nella fretta, il percorso URI veniva spesso scelto per la "figosità" piuttosto che per utilità o durabilità. Questa nota è un tentativo di reindirizzare l'energia dietro la ricerca della figosità.

Fonte: habr.com