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: sono le persone che li cambiano.

In teoria, le persone non hanno motivo di cambiare gli URI (o smettere di mantenere i documenti), ma nella pratica ce ne sono milioni.

Teoreticamente, il proprietario nominale dello spazio dei nomi di dominio possiede effettivamente lo spazio dei nomi di dominio e, di conseguenza, tutti gli URI in esso. A parte l'insolvenza, nulla impedisce al proprietario del nome di dominio di mantenere quel nome. E teoreticamente, lo spazio URI sotto il tuo nome di dominio è completamente sotto il tuo controllo, quindi puoi renderlo stabile quanto desideri. In una certa misura, l'unica ragione valida per cui un documento scompare da Internet è che l'azienda che possedeva il nome di dominio ha chiuso o non può più permettersi di mantenere il server operativo. Allora perché ci sono così tanti link interrotti nel mondo? In parte è semplicemente una mancanza di previsione. Ecco alcune ragioni che si possono sentire:

Abbiamo semplicemente riorganizzato il sito per renderlo migliore.

Pensi davvero che i vecchi URI non possano più funzionare? Se è così, li hai scelti molto male. Pensa a fare in modo che i nuovi siano conservati dopo il prossimo redesign.

Abbiamo così tanto materiale che non possiamo tenere traccia di ciò che è obsoleto, di ciò che è riservato e di ciò che è ancora rilevante, quindi abbiamo pensato che fosse meglio disattivare tutto ciò.

Posso solo esprimere la mia solidarietà. W3C ha attraversato un periodo in cui dovevamo setacciare attentamente i materiali archiviati per motivi di riservatezza prima di renderli pubblici. È necessaria una pianificazione anticipata: assicurati di registrare per ogni documento il pubblico accettabile, la data di creazione e, idealmente, la durata. Mantieni questi metadati.

Beh, abbiamo scoperto che dobbiamo spostare i file…

Questa è una delle scuse più tristi. Molti non sanno che i server web ti permettono di gestire la relazione tra l'URI di un oggetto e il suo effettivo posizionamento nel filesystem. Immagina lo spazio URI come uno spazio astratto, perfettamente organizzato. Poi effettua una mappatura nella realtà che stai effettivamente utilizzando per la sua implementazione. Infine, comunica tutto questo al server web. Puoi persino scrivere un frammento del tuo server per far funzionare tutto 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? Chiaro.

Prima usavamo uno script CGI per questo, ora utilizziamo un programma binario.

C'è l'idea folle che le pagine create da script debbano trovarsi nella zona "cgibin" o "cgi". Questo rivela il meccanismo di come si avvia il proprio server web. Se cambi il meccanismo (anche mantenendo il contenuto), e ops — 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 tra qualche anno. cgi-bin, oldbrowse e pl — tutto questo rivela frammenti di informazione su come lo facciamo ora. Se usi una pagina per cercare un documento, ottieni un risultato altrettanto scadente:

Rapporto del gruppo di lavoro sulla crittografia e teoria della codifica

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

Questo titolo pubs/1998 offrirà a qualsiasi futuro servizio di archivio una buona chiave per comprendere come 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à l'NSF o qualsiasi altra organizzazione che gestirà l'archivio.

Non pensavo che gli URL dovessero essere permanenti — ci sono state URN, giusto?

Probabilmente questo è uno degli effetti collaterali peggiori della discussione sulle URN. Alcuni pensano che, a causa delle ricerche su uno spazio dei nomi più permanente, possano trattare con superficialità i link interrotti, credendo che «le URN risolveranno tutto». Se sei una di queste persone, lascia che ti deluda.

La maggior parte degli schemi URN che ho visto sembrano essere un identificatore di autorità seguito da una data e una stringa a scelta oppure solo da una stringa a scelta. Questo è molto simile a un URI HTTP. In altre parole, se pensate che la vostra organizzazione sarà in grado di creare URN a lungo termine, dimostratelo ora utilizzandole per i vostri URI HTTP. Non c'è niente nell'HTTP che renda il vostro URI instabile. Solo la vostra organizzazione. Create un database che mappa l'URN del documento con il nome attuale del file e permettete al server web di utilizzarlo per il recupero effettivo dei file.

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

Volevamo farlo, ma semplicemente non abbiamo gli strumenti necessari.

Puoi davvero provare empatia per questo. Sono completamente d'accordo. Ciò che devi fare è far sì che il server web elabori immediatamente l'URI persistente e restituisca il file, dovunque esso sia attualmente archiviato nel tuo attuale sistema di file complesso. Vuoi conservare tutti gli URI in un file come verifica e mantenere costantemente aggiornato il database. Vuoi mantenere le relazioni tra le diverse versioni e traduzioni dello stesso documento, oltre a conservare una registrazione indipendente del checksum per garantire la protezione contro la corruzione del file causata da errori accidentali. E i server web non dispongono di queste funzionalità di default. Quando vuoi creare un nuovo documento, il tuo editor ti chiede di impostare l'URI.

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

Tutto è troppo brutto. Ma risolveremo la situazione. In W3C utilizziamo la funzionalità Jigedit (server Jigsaw per la modifica), che tiene traccia delle versioni, e stiamo sperimentando con gli 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 W3C, compresa questa: quindi fai ciò che dico, non ciò che faccio.

Perché dovrei preoccuparmi di questo?

Quando cambi URI sul tuo server, non puoi mai dire con certezza chi avrà i collegamenti all'URI precedente. Potrebbero essere collegamenti da normali pagine web. Segnalibri sulla tua pagina. L'URI potrebbe essere stato annotato ai margini di una lettera a un amico.

Quando qualcuno clicca su un link e questo non funziona, di solito perde fiducia nel proprietario del server. È anche deluso, sia emotivamente che concretamente, per l'impossibilità di raggiungere il suo obiettivo.

Molte persone si lamentano costantemente di link non funzionanti, e spero che il danno sia evidente. Spero sia anche chiaro il danno reputazionale per il mantenitore del server dove il documento è scomparso.

Allora, cosa devo fare? Progetta l'URI

È responsabilità del webmaster identificare URI che possano essere utilizzati tra 2 anni, 20 anni o 200 anni. Per questo ci vogliono pianificazione, organizzazione e determinazione.

Le URI cambiano se le informazioni in esse cambiano. È molto importante come le progettate. (Cosa, progettare URI? Devo progettare le URI? Sì, dovete pensarci). Progettare significa principalmente evitare qualsiasi informazione nelle URI.

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

L'unica eccezione è la pagina che è intenzionalmente l'«ultima» versione, per esempio, per tutta l'organizzazione o una sua grande parte.

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

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

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

(Appare bene. Presuppone che "money" significherà sempre la stessa cosa per tutta la durata di pathfinder.com. C'è una duplicazione di "98" e un ".html" non necessario, ma per il resto sembra un URI solido.

Cosa lasciare da parte

Niente! A parte la data di creazione, mettere qualsiasi informazione nell'URI ti espone in qualche modo a problemi.

Nome dell'autore. L'autore può cambiare con l'arrivo di nuove versioni. Le persone lasciano le organizzazioni e trasferiscono le cose ad altri.
Oggetto. È molto complicato. Appare sempre bene all'inizio, ma cambia sorprendentemente in fretta. Ne parlerò più nei dettagli qui sotto.
Stato. Le categorie come «vecchio», «bozza» e così via, per non parlare di «ultimo» e «fantastico», compaiono in tutti i sistemi di file. I documenti cambiano stato: altrimenti non avrebbe senso creare delle bozze. L'ultima versione del documento necessita 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 ovviamente i documenti iniziano come idee del team dei dipendenti, vengono discussi con i membri e poi diventano di pubblico dominio. È davvero peccato se ogni volta che un documento viene aperto a una discussione più ampia, tutti i vecchi link a esso smettono di funzionare! Ora passiamo a un semplice codice data.
Estensione del file. È un evento molto comune. "cgi", persino ".html" cambieranno in futuro. Potrebbe essere che fra 20 anni non utilizzerai HTML per questa pagina, ma i link di oggi a essa dovrebbero ancora funzionare. I link canonici sul sito W3C non usano l'estensione (come viene fatto).
Meccanismi software. Nel URI cercate "cgi", "exec" e altri termini che gridano «guardate quale software stiamo utilizzando». Qualcuno vuole dedicare tutta la vita agli script Perl CGI? No? Allora rimuovete l'estensione .pl. Leggete la guida del server su come farlo.
Nome del disco. Dai, davvero! Ma io ho visto cose del genere.

Quindi il miglior esempio dal nostro sito è semplicemente

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

… il verbale delle riunioni dei presidenti del W3C.

Temi e classificazione per temi

Parlerò più dettagliatamente di questo rischio, poiché è una delle cose più difficili da evitare. Di solito, i temi finiscono nell'URI quando classificate i vostri documenti in base al lavoro svolto. Ma questa suddivisione cambierà nel tempo. I nomi delle aree cambieranno. Al W3C volevamo cambiare MarkUP in Markup, e poi in HTML, per riflettere il reale contenuto della sezione. Inoltre, spesso qui c'è uno spazio dei nomi piatto. Dopo 100 anni, siete sicuri di non voler riutilizzare nulla? Nella nostra breve vita abbiamo già voluto riutilizzare termini come «Storia» e «Fogli di stile», per esempio.

È un modo allettante di organizzare un sito web — e davvero un modo affascinante di organizzare qualsiasi cosa, inclusa l'intera rete. È una buona soluzione a medio termine, ma presenta serie 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 un'interpretazione diversa di ciò che significa. Poiché le relazioni tra gli oggetti sono più simili a una rete che a un albero, anche coloro che concordano con la rete possono scegliere una diversa rappresentazione dell'albero. Questi sono i miei (spesso ripetuti) commenti generali sui pericoli della classificazione gerarchica come soluzione unica.

In effetti, quando utilizzi il nome di un tema nell'URI, ti stai legando a una certa classificazione. Potresti preferire un'altra opzione in futuro. Allora l'URI sarà soggetto a violazione.

Il motivo per cui si utilizza un dominio tematico come parte dell'URI è che la responsabilità per le sotto-aree dello spazio URI è solitamente delegata, e quindi è necessario un nome dell'ente organizzativo — sezione, gruppo o altro, responsabile di questo sottospazio. Questo lega l'URI alla struttura organizzativa. Di solito è sicuro solo quando ulteriormente (a sinistra) l'URI è protetto da una data: 1998/pics potrebbe significare per il vostro server «quello che intendavamo nel 1998 con pics», e non «quello che nel 1998 abbiamo fatto con ciò che ora chiamiamo pics».

Non dimenticate il nome di dominio

Ricordate che questo si riferisce non solo al percorso nell'URI, ma anche al nome del server. Se avete server separati per diverse funzioni, tenete presente che questa separazione sarà impossibile da modificare senza distruggere numerosi collegamenti. Alcuni errori classici come "guardate quale software stiamo usando oggi" — i nomi di dominio "cgi.pathfinder.com", "secure", "lists.w3.org". Sono stati creati per semplificare l'amministrazione dei server. Indipendentemente dal fatto che il dominio rappresenti una qualche divisione della vostra azienda, uno stato del documento, un livello di accesso o un livello di sicurezza, siate molto, molto cauti prima di utilizzare più di un nome di dominio per diversi tipi di documenti. Ricordate che potete nascondere numerosi server web all'interno di un unico server web visibile, utilizzando reindirizzamenti e proxy.

Sì, e pensate anche al vostro nome di dominio. Non volete che vengano fatti riferimenti a voi come a soap.com dopo aver cambiato la linea di prodotti e smesso di produrre sapone (Chiedo scusa a chi possiede soap.com in questo momento).

Conclusione

Mantenere un URI per 2, 20, 200 o addirittura 2000 anni non è così semplice come sembra. Tuttavia, nel vasto mondo di Internet, i webmaster prendono decisioni che rendono davvero difficile questo compito in futuro. Spesso accade perché utilizzano strumenti il cui obiettivo è presentare il miglior sito possibile solo nel momento attuale, senza considerare cosa succederà ai link quando tutto cambierà. Tuttavia, il punto è che molte cose, tante cose possono cambiare e i tuoi URI devono rimanere tali. Questo è possibile solo se pensi a come li crei.

Vedi anche:

Lamento di Jakob Nielsen sulla stessa tematica

Integrazioni

Come rimuovere le estensioni dei file…

…dagli URI nel server web attuale basato su file?

Se stai usando, ad esempio, Apache, puoi configurarlo per concordare il contenuto. Mantieni l'estensione del file (ad esempio, .png) nel file (esempio, mydog.png), ma è possibile fare riferimento a una risorsa web anche senza di essa. Successivamente, Apache controlla la cartella per la presenza di tutti i file con quel nome e qualsiasi estensione, e può anche scegliere il migliore da un insieme (ad esempio, GIF e PNG). E non è necessario mettere diversi tipi di file in diverse cartelle, in realtà la negoziazione dei contenuti non funzionerà se lo fai.

Configura il tuo server per la negoziazione dei contenuti
Fai sempre riferimento a URI senza estensione

I collegamenti con estensioni funzioneranno ancora, ma non permetteranno al tuo server di scegliere il migliore tra i formati attualmente disponibili e quelli futuri.

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

Certo, se stai scrivendo il tuo server web, sarebbe bene utilizzare un database per associare identificatori permanenti alla loro forma attuale, anche se fai attenzione a una crescita illimitata del database.

Tabellone dell'ignominia — Storia 1: Channel 7

Nel 1999 ho monitorato la chiusura delle scuole a causa della neve tramite la pagina http://www.whdh.com/stormforce/closings.shtml. Non possiamo aspettare che le informazioni appaiano in fondo allo schermo della TV! Ho messo un link alla pagina principale del mio sito. Arriva la prima grande tempesta di neve del 2000 e controllo la pagina. C'è scritto:

— Aggiornato il.
Attualmente non c'è nulla di chiuso. Per favore, tornate in caso di avvisi meteorologici.

Non può essere, una tempesta così forte. È divertente che la data sia assente. Ma se si va 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 avevano bisogno di cambiare l'URI.

La lista nera — Storia 2: Microsoft Netmeeting

Con la crescente dipendenza da Internet, è emersa l'idea intelligente di incorporare link al sito del produttore nelle applicazioni. Questo è stato spesso fatto e abusato, ma — non si può cambiare URL. Proprio qualche giorno fa ho provato un link dal client Microsoft Netmeeting 2/something nel menu Aiuto/Microsoft sul Web/Cose gratuite e ho ottenuto errore 404 — risposta del server non trovata. Forse è già stato sistemato...

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

Fonte: habr.com