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

Quale URI è considerato "interessante"?
Uno che non cambia.
Come vengono modificati gli URI?
Gli URI non cambiano: le persone li cambiano.

In teoria, non vi è alcun motivo per cui le persone debbano modificare gli URI (o interrompere i documenti di supporto), ma in pratica ce ne sono milioni.

In teoria, il proprietario nominale di uno spazio dei nomi di dominio possiede effettivamente lo spazio dei nomi di dominio e quindi tutti gli URI al suo interno. A parte l'insolvenza, nulla impedisce al titolare di un nome a dominio di mantenerlo. E in teoria, lo spazio URI sotto il tuo nome di dominio è interamente sotto il tuo controllo, quindi puoi renderlo stabile come preferisci. Praticamente l'unica buona ragione per cui un documento scompare da Internet è che la società proprietaria del nome di dominio ha cessato l'attività o non può più permettersi di mantenere il server in funzione. Allora perché ci sono così tanti anelli mancanti nel mondo? In parte ciò è semplicemente una mancanza di lungimiranza. Ecco alcuni motivi che potresti sentire:

Abbiamo appena riorganizzato il sito per renderlo migliore.

Pensi davvero che i vecchi URI non possano più funzionare? Se è così, allora li hai scelti molto male. Considera la possibilità di mantenere quelli nuovi per la prossima riprogettazione.

Abbiamo così tante cose che non riusciamo a tenere traccia di ciò che non è aggiornato, di ciò che è confidenziale e di ciò che è ancora rilevante, quindi abbiamo pensato che fosse meglio disattivare tutto.

Posso solo simpatizzare. Il W3C ha attraversato un periodo in cui abbiamo dovuto vagliare attentamente la riservatezza dei materiali d'archivio prima di renderli pubblici. La decisione dovrebbe essere pensata in anticipo: assicurati di registrare con ciascun documento il numero di lettori accettabili, la data di creazione e, idealmente, la data di scadenza. Salva questi metadati.

Bene, abbiamo scoperto che dobbiamo spostare i file...

Questa è una delle scuse più patetiche. Molte persone non sanno che i server web consentono di controllare la relazione tra l'URI di un oggetto e la sua effettiva posizione nel file system. Pensa allo spazio URI come a uno spazio astratto, perfettamente organizzato. Quindi fai una mappatura di qualunque realtà tu usi effettivamente per realizzarla. Quindi segnalalo al server web. Puoi anche scrivere il tuo snippet del server per farlo bene.

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

Il nome di John era nell'URI? No, il file era solo nella sua directory? Allora ok.

In precedenza utilizzavamo uno script CGI per questo, ma ora utilizziamo un programma binario.

C'è l'idea folle che le pagine create dagli script debbano essere posizionate nell'area "cgibin" o "cgi". Questo espone i meccanismi di come gestisci il tuo server web. Modifichi il meccanismo (anche durante il salvataggio del contenuto) e, ops, tutti i tuoi URI cambiano.

Prendiamo ad esempio la National Science Foundation (NSF):

Documenti on-line NSF

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

La prima pagina su cui iniziare a visualizzare i documenti chiaramente non rimarrà la stessa tra qualche anno. cgi-bin, oldbrowse и pl - Tutto ciò fornisce informazioni su come lo facciamo adesso. Se utilizzi la pagina per cercare un documento, il primo risultato che ottieni è altrettanto pessimo:

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

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

per la pagina dell'indice del documento, sebbene il documento html stesso abbia un aspetto molto migliore:

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

Qui l'intestazione pubs/1998 fornirà a qualsiasi futuro servizio di archiviazione un buon indizio sul fatto che il vecchio schema di classificazione dei documenti del 1998 è in vigore. Sebbene i numeri dei documenti possano apparire diversi nel 2098, immagino che questo URI sarebbe ancora valido e non interferirebbe con NSF o qualsiasi altra organizzazione che manterrebbe l'archivio.

Non pensavo che gli URL dovessero essere persistenti: c'erano gli URN.

Questo è probabilmente uno dei peggiori effetti collaterali del dibattito sulle URN. Alcune persone pensano che, a causa della ricerca su uno spazio dei nomi più permanente, potrebbero essere incuranti dei collegamenti penzolanti perché "gli URN risolveranno tutto questo". Se sei una di queste persone, lascia che ti deluda.

La maggior parte degli schemi URN che ho visto assomigliano a un identificatore di autorità seguito da una data e da una stringa selezionata o semplicemente da una stringa selezionata. Questo è molto simile a un URI HTTP. In altre parole, se ritieni che la tua organizzazione sarà in grado di creare URN di lunga durata, dimostralo ora utilizzandoli per i tuoi URI HTTP. Non c'è nulla nell'HTTP stesso che renda instabile il tuo URI. Solo la tua organizzazione. Creare un database che associ l'URN del documento al nome del file corrente e consentire al server Web di utilizzarlo per recuperare effettivamente i file.

Se sei arrivato a questo punto, se non hai tempo, denaro e contatti per sviluppare qualche software, allora puoi addurre la seguente scusa:

Avremmo voluto farlo, ma non abbiamo gli strumenti giusti.

Ma puoi simpatizzare con questo. Sono completamente d'accordo. Quello che devi fare è forzare il server web ad analizzare istantaneamente l'URI persistente e restituire il file ovunque sia attualmente archiviato sul tuo attuale file system pazzo. Desideri memorizzare tutti gli URI in un file come controllo e mantenere il database sempre aggiornato. Desideri preservare la relazione tra diverse versioni e traduzioni dello stesso documento e anche mantenere un record di checksum indipendente per garantire che il file non venga danneggiato da un errore accidentale. E i server web semplicemente non sono pronti all'uso con queste funzionalità. Quando vuoi creare un nuovo documento, il tuo editor ti chiede di specificare un URI.

È necessario essere in grado di modificare la proprietà, l'accesso ai documenti, la sicurezza a livello di archivio, ecc. nello spazio URI senza modificare l'URI.

È tutto un peccato. Ma correggeremo la situazione. Al W3C utilizziamo la funzionalità Jigedit (server di editing Jigsaw) che tiene traccia delle versioni e sperimentiamo script per la creazione di documenti. Se sviluppi strumenti, server e client, presta attenzione a questo problema!

Questa scusa vale anche per molte pagine del W3C, compresa questa: quindi fate quello che dico, non quello che faccio.

Perchè dovrebbe interessarmi?

Quando modifichi l'URI sul tuo server, non puoi mai sapere completamente chi avrà i collegamenti al vecchio URI. Questi possono essere collegamenti da normali pagine Web. Aggiungi la tua pagina ai segnalibri. L'URI potrebbe essere stato scarabocchiato a margine di una lettera a un amico.

Quando qualcuno segue un collegamento e questo viene interrotto, di solito perde la fiducia nel proprietario del server. È anche frustrato, sia emotivamente che fisicamente, per non riuscire a raggiungere il suo obiettivo.

Molte persone si lamentano continuamente dei collegamenti interrotti e spero che il danno sia evidente. Spero che sia evidente anche il danno reputazionale a carico del manutentore del server dove il documento è scomparso.

Quindi cosa dovrei fare? Progettazione dell'URI

È responsabilità del webmaster allocare URI che potranno essere utilizzati tra 2 anni, tra 20 anni, tra 200 anni. Ciò richiede attenzione, organizzazione e determinazione.

Gli URI cambiano se cambiano le informazioni in essi contenute. Il modo in cui li progetti è molto importante. (Cosa, progettazione dell'URI? Devo progettare l'URI? Sì, dovresti pensarci). Progettare significa fondamentalmente tralasciare qualsiasi informazione nell'URI.

La data di creazione del documento, ovvero la data di emissione dell'URI, è qualcosa che non cambierà mai. È molto utile per separare le query che utilizzano il nuovo sistema da quelle che utilizzano il vecchio sistema. Questo è un buon punto di partenza con un URI. Se un documento è datato, anche se sarà rilevante in futuro, allora questo è un buon inizio.

L'unica eccezione è una pagina che è intenzionalmente la versione "più recente", ad esempio per l'intera organizzazione o gran parte di essa.

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

Questa è l'ultima rubrica di Money Daily sulla rivista Money. Il motivo principale per cui non è necessaria una data in questo URI è che non esiste alcun motivo per archiviare l'URI che sopravvivrà al registro. Il concetto di Money Daily scomparirà quando scomparirà Money. Se desideri collegarti al contenuto, devi collegarlo separatamente negli archivi:

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

(Sembra buono. Presuppone che "denaro" significherà la stessa cosa per tutta la vita di pathfinder.com. C'è un duplicato "98" e un ".html" non necessario, ma per il resto sembra un URI forte.

Cosa lasciare da parte

Tutto! A parte la data di creazione, inserire qualsiasi informazione nell'URI crea problemi in un modo o nell'altro.

• Nome dell'autore. La paternità può cambiare man mano che diventano disponibili nuove versioni. Le persone lasciano le organizzazioni e trasmettono le cose ad altri.
• soggetto. È molto difficile. All'inizio sembra sempre bello, ma cambia sorprendentemente rapidamente. Ne parlerò più approfonditamente di seguito.
• stato. Directory come "old", "draft" e così via, per non parlare di "latest" e "cool", compaiono in tutti i file system. I documenti cambiano stato, altrimenti non avrebbe senso creare bozze. L'ultima versione di un documento necessita di un identificatore persistente, indipendentemente dal suo stato. Mantieni lo stato fuori dal nome.
• accesso. Al W3C abbiamo diviso il sito in sezioni per dipendenti, membri e pubblico. Sembra una cosa positiva, ma ovviamente i documenti nascono come idee di gruppo provenienti dallo staff, vengono discussi con i membri e poi diventano di pubblico dominio. Sarebbe davvero un peccato se ogni volta che un documento viene aperto per una discussione più ampia, tutti i vecchi collegamenti ad esso venissero interrotti! Ora passiamo ad un semplice codice data.
• Estensione del file. Un evento molto comune. "cgi", anche ".html" cambieranno in futuro. Potresti non utilizzare HTML per questa pagina tra 20 anni, ma i collegamenti di oggi ad essa dovrebbero funzionare ancora. I collegamenti canonici sul sito W3C non utilizzano l'estensione (come è fatto).
• Meccanismi software. Nell'URI, cerca "cgi", "exec" e altri termini che urlano "guarda quale software stiamo utilizzando". Qualcuno vorrebbe passare tutta la vita a scrivere script Perl CGI? NO? Quindi rimuovere l'estensione .pl. Leggi il manuale del server su come eseguire questa operazione.
• Nome del disco. Dai! Ma ho visto questo.

Quindi il miglior esempio dal nostro sito è semplicemente

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

...riportare il verbale dell'incontro dei presidenti del W3C.

Argomenti e classificazione per argomento

Entrerò più nel dettaglio su questo pericolo, poiché è una di quelle cose più difficili da evitare. In genere, gli argomenti finiscono negli URI quando classifichi i tuoi documenti in base al lavoro che svolgono. Ma questa ripartizione cambierà nel tempo. I nomi delle aree cambieranno. Al W3C volevamo cambiare MarkUP in Markup e poi in HTML per riflettere il contenuto effettivo della sezione. Inoltre, spesso esiste uno spazio dei nomi piatto. Tra 100 anni sei sicuro che non vorrai riutilizzare nulla? Nella nostra breve vita abbiamo già voluto riutilizzare “Storia” e “Fogli di Stile” ad esempio.

È un modo allettante di organizzare un sito Web e un modo davvero allettante di organizzare qualsiasi cosa, incluso l'intero Web. Si tratta di un’ottima soluzione a medio termine, ma presenta gravi carenze a lungo termine.

Parte della ragione risiede nella filosofia del significato. Ogni termine in una lingua è un potenziale bersaglio per il clustering e ogni persona può avere un'idea diversa di cosa significhi. Poiché le relazioni tra entità sono più simili a una rete che a un albero, anche coloro che sono d'accordo con la rete possono scegliere una diversa rappresentazione dell'albero. Queste sono le mie osservazioni generali (spesso ripetute) sui pericoli della classificazione gerarchica come soluzione generale.

Infatti, quando usi il nome di un argomento in un URI, ti impegni in una sorta di classificazione. Forse in futuro preferirai un'opzione diversa. L'URI sarà quindi suscettibile di violazione.

La ragione per utilizzare un'area tematica come parte di un URI è che la responsabilità per le sottosezioni dello spazio URI è solitamente delegata e quindi è necessario il nome dell'ente organizzativo (dipartimento, gruppo o altro) responsabile di quel sottospazio. Si tratta di un collegamento URI a una struttura organizzativa. Di solito è sicuro solo se l'URI più lontano (a sinistra) è protetto da una data: 1998/pics potrebbe significare per il tuo server "cosa intendevamo nel 1998 con le foto" piuttosto che "cosa abbiamo fatto nel 1998 con ciò che ora chiamiamo foto".

Non dimenticare il nome del dominio

Ricorda che questo vale non solo per il percorso nell'URI, ma anche per il nome del server. Se disponi di server separati per cose diverse, ricorda che questa divisione sarà impossibile da modificare senza distruggere molti, molti collegamenti. Alcuni errori classici del tipo "guarda il software che usiamo oggi" sono i nomi di dominio "cgi.pathfinder.com", "secure", "lists.w3.org". Sono progettati per semplificare l'amministrazione del server. Indipendentemente dal fatto che un dominio rappresenti una divisione della tua azienda, uno stato di documento, un livello di accesso o un livello di sicurezza, fai molta, molta attenzione prima di utilizzare più di un nome di dominio per più tipi di documenti. Ricorda che puoi nascondere più server Web all'interno di un singolo server Web visibile utilizzando il reindirizzamento e il proxy.

Oh, e pensa anche al tuo nome di dominio. Non vuoi essere chiamato soap.com dopo aver cambiato linea di prodotti e smesso di produrre sapone (mi spiace con chi possiede soap.com al momento).

conclusione

Preservare un URI per 2, 20, 200 o anche 2000 anni ovviamente non è così facile come sembra. Tuttavia, ovunque in Internet, i webmaster stanno prendendo decisioni che renderanno questo compito davvero difficile per loro in futuro. Spesso ciò accade perché utilizzano strumenti il ​​cui compito è presentare il sito migliore solo al momento - e nessuno ha valutato cosa accadrà ai collegamenti quando tutto cambierà. Tuttavia, il punto qui è che molte, molte cose possono cambiare e i tuoi URI possono e devono rimanere gli stessi. Questo è possibile solo quando pensi a come crearli.

Vedi anche:

• La tirata di Jakob Nielsen sullo stesso argomento

supplementi

Come rimuovere le estensioni dei file...

...da un URI nell'attuale server Web basato su file?

Se usi Apache, ad esempio, puoi configurarlo per negoziare i contenuti. Salvare l'estensione del file (ad esempio .png) in un file (ad esempio miocane.png), ma puoi collegarti a una risorsa Web senza di essa. Apache quindi controlla la directory per tutti i file con quel nome e qualsiasi estensione e può scegliere il migliore dal set (ad esempio GIF e PNG). E non è necessario inserire diversi tipi di file in directory diverse, infatti la corrispondenza dei contenuti non funzionerà se lo fai.

• Configura il tuo server per negoziare i contenuti
• Collega sempre agli URI senza estensione

I collegamenti con le estensioni continueranno a funzionare, ma impediranno al tuo server di scegliere il miglior formato disponibile attualmente e in futuro.

(Infatti, mydog, mydog.png и mydog.gif — risorse web valide, mydog è una risorsa di tipo di contenuto universale e mydog.png и mydog.gif — risorse di un tipo di contenuto specifico).

Naturalmente, se stai scrivendo il tuo server web, è una buona idea utilizzare un database per associare gli identificatori persistenti alla loro forma corrente, ma fai attenzione alla crescita illimitata del database.

Il consiglio della vergogna - Storia 1: Canale 7

Nel corso del 1999 ho seguito la chiusura delle scuole per neve a pag http://www.whdh.com/stormforce/closings.shtml. Non aspettare che le informazioni appaiano nella parte inferiore dello schermo TV! L'ho linkato dalla mia home page. Arriva la prima grande tempesta di neve del 2000 e controllo la pagina. È scritto lì:,

- Come di.
Al momento non c'è nulla di chiuso. Si prega di ritornare in caso di allerta meteo.

Non può essere una tempesta così forte. È buffo che manchi la data. Ma se andate alla pagina principale del sito, troverete un grande pulsante “Scuole Chiuse”, che porta alla pagina http://www.whdh.com/stormforce/ con un lungo elenco di scuole chiuse.

Forse hanno cambiato il sistema per ottenere l'elenco, ma non è stato necessario modificare l'URI.

Board of Shame - Storia 2: Microsoft Netmeeting

Con la crescente dipendenza da Internet è nata l’idea intelligente di incorporare nelle applicazioni dei link al sito web del produttore. Questo è stato usato e abusato molto, ma non è possibile modificare l'URL. Proprio l'altro giorno ho provato un collegamento dal client Microsoft Netmeeting 2/qualcosa nel menu Guida/Microsoft sul Web/Roba gratuita e ho ricevuto un errore 404: non è stata trovata alcuna risposta dal server. Magari è già risolto...

© 1998 Tim BL

Nota storica: alla fine del XX secolo, quando fu scritto questo, "cool" era un epiteto di approvazione, soprattutto tra i giovani, che indicava moda, qualità o adeguatezza. In tutta fretta, il percorso dell'URI veniva spesso scelto per la "bellezza" piuttosto che per l'utilità o la durabilità. Questo post è un tentativo di reindirizzare l'energia dietro la ricerca del bello.

Fonte: habr.com