26 mar 2025·8 min
Il web di Tim Berners-Lee: URL, HTTP, HTML e perché conta
Scopri come Tim Berners-Lee ha combinato URL, HTTP e HTML per creare il World Wide Web — e perché queste idee semplici alimentano ancora le app e le API moderne.
Scopri come Tim Berners-Lee ha combinato URL, HTTP e HTML per creare il World Wide Web — e perché queste idee semplici alimentano ancora le app e le API moderne.
Il World Wide Web (spesso semplicemente “il Web”) è un modo per pubblicare e accedere a informazioni tramite collegamenti. È il sistema che ti permette di cliccare da una pagina all'altra, aprire la scheda prodotto da un risultato di ricerca o condividere un link che funziona su quasi qualsiasi computer o telefono.
Alla base, il Web si regge su un trio pratico:
Non serve essere programmatori per percepirne l'impatto: ogni volta che incolli un link, carichi una pagina o clicchi un pulsante che ti porta da qualche parte, stai usando URL + HTTP + HTML.
Molti usano “Web” e “Internet” come sinonimi, ma sono diversi:
Email, giochi online e molte app di chat usano Internet senza essere “il Web” nel senso stretto.
Anche le esperienze moderne—single-page app, app mobili e API—si basano ancora molto su queste fondamenta. Possono nascondere i dettagli, ma continuano a usare URL per identificare risorse, HTTP per scambiare richieste e risposte e spesso HTML per avviare ciò che vedi nel browser.
Tim Berners-Lee non stava cercando di inventare “Internet”. Nel 1989, mentre lavorava al CERN, era concentrato su una frustrazione pratica: informazioni importanti esistevano ma erano sparse su sistemi incompatibili, salvate in formati diversi e difficili da ritrovare.
Ricercatori, team e dipartimenti usavano computer e software diversi. Anche quando due gruppi avevano lo stesso tipo di documento, potevano conservarlo in posti diversi, chiamarlo in modo diverso o richiedere un programma speciale per aprirlo. Condividere spesso significava inviare file, duplicare copie e perdere il controllo di quale fosse la versione aggiornata.
L'idea centrale di Berners-Lee era permettere a chiunque di pubblicare un documento sul proprio computer e far sì che altri lo raggiungessero con un metodo coerente—senza dover conoscere il tipo di macchina, il sistema operativo o la struttura di directory interna.
Ciò richiedeva che alcune cose funzionassero insieme:
La svolta non fu una singola caratteristica, ma la decisione di mantenere il sistema piccolo e universale. Se le regole erano abbastanza semplici, computer e organizzazioni diverse potevano implementarle e comunicare comunque.
Per questo gli standard aperti furono importanti fin dall'inizio: il web aveva bisogno di regole pubbliche condivise affinché molti sistemi indipendenti potessero partecipare. Questa focalizzazione su standard comuni—piuttosto che su toolchain proprietarie—permise al web di diffondersi rapidamente e a nuovi browser e server di funzionare con contenuti esistenti.
Se hai mai provato a “condividere un file” in un drive disordinato dell'ufficio, hai visto il problema principale delle reti: dare nomi coerenti alle cose è difficile. Computer diversi salvano informazioni in posti diversi, le cartelle vengono riorganizzate e due documenti possono avere lo stesso nome. Senza un sistema di nomenclatura condiviso non puoi dire in modo affidabile “prendi quella cosa laggiù”.
Gli URL hanno risolto questo problema per il World Wide Web fornendo un indirizzo universale copiabile e incollabile per una risorsa.
Ecco un esempio che potrebbe esserti familiare:
https://www.example.com:443/products/shoes?color=black\u0026size=42#reviews
Cosa significa ogni parte (in parole semplici):
Un URL può identificare quasi tutto ciò che un server può restituire: una pagina HTML, un'immagine, un PDF, un file scaricabile o perfino un endpoint API usato da un'app.
Per esempio:
/images/logo.png (un'immagine)/docs/terms.pdf (un documento)/api/orders/123 (dati per un'applicazione)Spesso questi termini sono usati come sinonimi:
Per scopi pratici, pensare “URL = indirizzo” ti porterà al 95% dei casi.
HTTP è lo stile di conversazione di base del web. È un accordo semplice: il tuo browser chiede qualcosa e un server risponde con ciò che ha (o con una spiegazione del perché non può).
Quando digiti un URL o clicchi un link, il browser invia una richiesta HTTP a un server. La richiesta è come un biglietto che dice: “Voglio questa risorsa specifica.”
Il server quindi invia una risposta HTTP. La risposta è il pacchetto che contiene il risultato: il contenuto richiesto (come una pagina) o un messaggio che qualcosa è andato diversamente.
Le richieste HTTP includono un metodo, che è semplicemente il tipo di azione che stai compiendo.
Una GET di solito non modifica nulla sul server; serve principalmente per leggere. Una POST è usata quando invii informazioni da elaborare.
Ogni risposta include un codice di stato—pensalo come l'esito della consegna.
Richieste e risposte includono anche header, che sono come etichette: “Questo è chi sono,” “Questo è ciò che accetto,” o “Così va gestito questo contenuto.”
Una delle etichette più utili è Content-Type, come text/html per una pagina web o application/json per dati. Dice al browser cosa c'è dentro così può mostrarlo correttamente.
HTML (HyperText Markup Language) è il formato usato per descrivere la struttura di una pagina web—cosa contiene e come è organizzato. Pensalo come un documento con etichette: “questo è un titolo,” “questo è un paragrafo,” “questo è un link,” “questo è un campo di un form.”
HTML usa tag per segnare il contenuto. Un tag ha di solito una versione di apertura e una di chiusura che racchiudono ciò che descrivono.
Titoli e paragrafi danno forma alla pagina. Un titolo dice sia alle persone sia ai browser “questa è un'intestazione importante.” Un paragrafo dice “questo è testo di corpo.”
Anche link e immagini sono descritti in HTML. Un tag immagine punta a un file immagine (una risorsa), mentre un tag di link punta a un altro URL.
L’“HT” in HTML—hypertext—è l'idea che ha reso il web diverso dai sistemi precedenti. Invece di navigare solo con menu, cartelle o comandi speciali, potevi saltare direttamente da un documento a un altro usando link cliccabili incorporati nel testo.
Questa svolta è semplice ma potente: la conoscenza diventa connessa. Una pagina può riferire fonti, argomenti correlati, definizioni e passi successivi all'istante—senza dover tornare a un indice centrale ogni volta.
Ecco come appare un link di base:
\u003ca href=\"/blog/how-http-works\"\u003eRead more about HTTP\u003c/a\u003e
In parole semplici: “Mostra le parole Read more about HTTP e, quando cliccate, porta il lettore alla pagina /blog/how-http-works.”
L'HTML non serve solo a pubblicare documenti. Può anche descrivere input come campi di testo, checkbox e pulsanti. Questi elementi permettono a una pagina di raccogliere informazioni (come un login, una ricerca o un checkout) e inviarle a un server.
È facile confonderli, ma hanno compiti diversi:
Anche con app web complesse, l'HTML resta il punto di partenza: è il modo condiviso e leggibile per descrivere cosa contiene una pagina—e dove può portare dopo.
Quando visiti un sito, il browser svolge fondamentalmente due lavori: trovare il computer giusto con cui parlare e chiedere il file giusto.
Un URL (come https://example.com/page) è l'indirizzo della pagina. Include un nome host (example.com) e spesso un percorso (/page).
I computer su internet parlano usando indirizzi numerici chiamati indirizzi IP. DNS (Domain Name System) è come una rubrica telefonica che mappa example.com a un indirizzo IP.
Questa ricerca è di solito veloce—e a volte viene saltata perché la risposta è già memorizzata da una visita recente.
Ora il browser apre una connessione al server a quell'indirizzo IP. Se l'URL inizia con https://, il browser stabilisce anche una connessione cifrata affinché altri non possano leggere facilmente ciò che viene inviato.
HTTP è il linguaggio di “richiesta e risposta” del web. Il browser invia una richiesta HTTP tipo: “Per favore dammi /page.”
Il server risponde con una risposta HTTP che include uno stato (come “OK” o “Not Found”) e il contenuto.
Quel contenuto è spesso HTML. Mentre il browser legge l'HTML, può scoprire di aver anche bisogno di altri file (CSS per lo stile, JavaScript per l'interazione, immagini, font). Ripete il pattern richiesta/risposta HTTP per ciascuno.
Per accelerare, i browser mantengono una cache—una copia salvata dei file già scaricati. Se nulla è cambiato, il browser può riutilizzare quella copia invece di riscaricarla.
Checklist rapida (flusso):
Quando si parla di “web” si pensa spesso a un'esperienza fluida: tocchi un link e appare una pagina. Sotto, è una relazione semplice tra tre idee: server, browser e risorse.
Un server è un computer (o un cluster di computer) connesso a internet che ospita risorse a URL. Se un URL è un indirizzo, il server è il luogo che riceve i visitatori a quell'indirizzo e decide cosa inviare indietro.
Quella “cosa” che il server invia può essere una pagina web, un file o dei dati. L'importante è che il server sia configurato per rispondere alle richieste per URL specifici.
Un browser è un programma (come Chrome, Safari o Firefox) che recupera risorse dai server e le mostra in modo comprensibile.
Quando inserisci un URL o clicchi un link, il browser:
Una risorsa è qualsiasi cosa che il web può identificare e consegnare a un URL. Esempi comuni includono:
Questo stesso modello non è limitato ai browser. Un'app mobile può anche richiedere un URL—tipicamente un endpoint API web—e ricevere dati da mostrare nell'interfaccia dell'app. I ruoli restano: app come “client”, server come “host” e la risposta API come risorsa.
Le prime pagine web mostravano soprattutto informazioni. I form permettono al web di raccogliere informazioni—trasformando una pagina in una conversazione a due vie.
Un form HTML è un insieme strutturato di campi (caselle di testo, checkbox, pulsanti) con due istruzioni chiave:
action)method, solitamente GET o POST)Quando clicchi “Invia”, il browser impacchetta ciò che hai digitato e lo manda via HTTP al server all'URL indicato. Quello è il ponte tra “un documento con campi” e “un'applicazione che elabora input”.
In breve:
Quindi una ricerca potrebbe apparire come /search?q=shoes (GET), mentre un invio di checkout potrebbe POSTare i dettagli dell'ordine a /checkout.
Lato server, un programma riceve la richiesta HTTP, legge i valori inviati e decide cosa fare:
Il server poi risponde—spesso con una nuova pagina HTML (“Grazie!”), un messaggio di errore o un redirect verso un altro URL.
Se un form include dati sensibili—password, indirizzi, dettagli di pagamento—HTTPS è essenziale. Previene che altri sulla rete leggano o alterino ciò che viene inviato tra browser e sito. Senza di esso, persino un semplice form di login può esporre gli utenti.
Le moderne “app” sul Web non sono solo pagine. La maggior parte è web più codice: una pagina HTML che carica JavaScript e CSS, poi usa quel codice per aggiornare ciò che vedi senza ricaricare l'intera pagina.
Anche quando un'app sembra nativa (feed a scorrimento infinito, aggiornamenti in tempo reale, drag-and-drop), si basa sugli stessi tre mattoni introdotti da Tim Berners-Lee.
Un URL non è solo per “una pagina”. È un indirizzo per qualsiasi risorsa: un prodotto, un profilo utente, una query di ricerca, una foto o un endpoint per inviare un messaggio. Buone app usano URL per rendere i contenuti condivisibili, salvabili e linkabili—comportamenti base del Web.
Dietro le quinte, le app inviano richieste HTTP e ricevono risposte HTTP, proprio come i siti classici. Le regole sono le stesse sia che tu stia richiedendo una pagina HTML sia che tu stia caricando dati per una parte dello schermo:
La maggior parte delle app moderne comunica con API: URL che restituiscono dati—spesso JSON—tramite HTTP.
Per esempio:
L'HTML resta importante perché spesso è il punto di partenza (e a volte il fallback). Più in generale, il Web è una piattaforma di integrazione: se i sistemi concordano su URL e HTTP, possono collegarsi—qualunque sia l'autore.
Un modo pratico per vedere questi mattoni in azione è costruire qualcosa di piccolo—per esempio un front end React che parla con un'API JSON e ha URL condivisibili per schermate chiave. Strumenti come Koder.ai seguono lo stesso modello: descrivi l'app in chat e genera uno stack web standard (React sul front end, Go + PostgreSQL sul back end), quindi lavori ancora con veri URL, endpoint HTTP e HTML servito dal browser—ma con molto meno setup manuale.
Il Web funziona su scala globale perché si basa su standard condivisi—regole pubbliche che permettono a sistemi diversi di comunicare in modo affidabile. Un browser di una compagnia può richiedere una pagina a un server gestito da un'altra, ospitato ovunque e scritto in qualsiasi linguaggio di programmazione, perché concordano su elementi come URL, HTTP e HTML.
Senza standard, ogni sito richiederebbe un'app personalizzata per essere visto e ogni rete avrebbe un modo privato di inviare richieste. La standardizzazione risolve problemi semplici ma critici:
Quando quelle regole sono coerenti, il Web diventa “mix and match”: qualsiasi browser conforme + qualsiasi server conforme = funziona.
La parte impressionante è che gli standard possono migliorare mantenendo i fondamenti riconoscibili. HTTP è passato dalle prime versioni a HTTP/1.1, poi a HTTP/2 e HTTP/3, aggiungendo prestazioni e efficienza. L'idea centrale resta la stessa: un client richiede un URL, un server risponde con codice di stato, header e body.
Anche HTML è cresciuto—da documenti semplici a semanticità più ricca e media incorporati—pur conservando il concetto base di pagine e hyperlink.
Gran parte della longevità del Web viene da una forte preferenza per la retrocompatibilità. I nuovi browser cercano ancora di rendere pagine vecchie; i nuovi server capiscono richieste HTTP più datate. Questo significa che contenuti e link possono vivere per anni—spesso decenni.
Se vuoi che il tuo sito o la tua app invecchi bene, appoggiati al design basato su standard: usa URL reali per stati condivisibili, segui le convenzioni HTTP per caching e codici di stato e scrivi HTML valido prima di aggiungere ulteriori livelli. Gli standard non sono limitanti—sono ciò che rende il tuo lavoro portabile, affidabile e orientato al futuro.
Anche se usi il web ogni giorno, alcuni termini si confondono così spesso che possono mandare fuori strada troubleshooting, pianificazione o semplici conversazioni. Ecco i fraintendimenti più comuni e come correggerli in fretta.
Fraintendimento: Internet e World Wide Web sono la stessa cosa.
Correzione rapida: L'Internet è la rete globale (cavi, router, connessioni). Il Web è un servizio che gira sopra di essa, costruito su URL, HTTP e HTML.
Fraintendimento: “Il mio URL è example.com.”
Correzione rapida: example.com è un dominio. Un URL è un indirizzo completo che può includere percorso, query e altro, come:
https://example.com/pricing (una rotta specifica)https://example.com/search?q=shoes (una rotta con query)Quelle parti extra possono cambiare cosa restituisce il server.
Fraintendimento: HTML e HTTP sono intercambiabili.
Correzione rapida: HTTP è la “conversazione di consegna” (richiesta e risposta). HTML è uno dei possibili “pacchetti” consegnati—spesso quello che descrive una pagina e i suoi link. HTTP può anche consegnare JSON, immagini, PDF o video.
Fraintendimento: Qualunque errore significa “il sito è down” e i redirect sono sempre negativi.
Correzione rapida: I codici di stato sono segnali:
Fraintendimento: Ogni URL dovrebbe aprire una pagina leggibile dall'uomo.
Correzione rapida: Un URL può puntare a dati (/api/orders), a un file (/report.pdf) o a un endpoint d'azione per l'invio di un form.
Fraintendimento: Se è HTTPS, il sito è sicuro e affidabile.
Correzione rapida: HTTPS cifra la connessione e aiuta a confermare che stai parlando con il dominio giusto—ma non garantisce che l'azienda sia affidabile. Valuta comunque:
L'idea centrale di Tim Berners-Lee era sorprendentemente piccola: collegare documenti (e poi applicazioni) usando uno schema di indirizzamento condiviso, un modo condiviso per richiedere dati e un formato condiviso per mostrarli e collegarli.
URL è l'indirizzo. Dice cosa vuoi e dove risiede (e spesso come raggiungerlo).
HTTP è la conversazione. È l'insieme di regole che browser e server usano per chiedere qualcosa e rispondere (codici di stato, header, caching e altro).
HTML è il formato della pagina. È ciò che un browser legge per rendere contenuti—ed è dove i link connettono una risorsa all'altra.
Pensa al web come a un semplice ciclo in tre passaggi:
Con questo loop in testa, i dettagli moderni (cookie, API, single-page app, CDN) diventano più facili da comprendere: sono in genere perfezionamenti di denominazione, richiesta o rendering.
Se vuoi approfondire senza entrare troppo nel tecnico:
Capire queste basi ripaga subito: sarai più efficace nel valutare strumenti web (“Questo si basa su URL e HTTP standard?”), nel comunicare con gli sviluppatori e nel risolvere problemi quotidiani come link rotti, cache o differenze tra “404 vs 500” errori.
Internet è la rete globale (router, cavi, instradamento IP) che connette i computer. Il Web è un servizio che funziona sopra di essa: risorse identificate da URL, trasferite con HTTP e spesso visualizzate come HTML.
Molte cose usano Internet senza essere “il Web”, come le email, alcuni giochi multiplayer e molte piattaforme di chat.
Pensa a un URL come a un indirizzo preciso per una risorsa. Può puntare a una pagina HTML, un'immagine, un PDF o un endpoint API.
Un URL tipico include:
https) — come accederviUn dominio (come example.com) è solo il nome di un host. Un URL può includere molti più dettagli—come il percorso e la query—che cambiano ciò che il server restituisce.
Per esempio:
https://example.com/pricinghttps://example.com/search?q=shoesIl fragment (la parte dopo #) è gestito dal browser e non viene inviato al server nella richiesta HTTP.
Usi comuni:
#reviews)Se cambi solo il fragment, spesso non si innesca un ricaricamento completo della pagina.
HTTP sono le regole per la conversazione di richiesta e risposta tra un client (browser/app) e un server.
Nella pratica:
Usa GET quando stai recuperando qualcosa (intento di sola lettura), come caricare una pagina o ottenere dati.
Usa POST quando stai inviando dati da elaborare, come creare un account, postare un commento o completare un checkout.
Consiglio pratico: se l'azione deve essere facilmente condivisibile o preferibile da salvare nei segnalibri (es. una ricerca), è solitamente la scelta migliore; se cambia lo stato del server, è il comportamento tipico.
I codici di stato riassumono l'esito di una richiesta:
Quando fai troubleshooting, un spesso indica un URL errato o una pagina eliminata; un di solito segnala un bug o un malfunzionamento lato server.
Il browser ha bisogno di un indirizzo IP per connettersi a un server. DNS (Domain Name System) è il sistema che traduce un nome umano leggibile (come example.com) in un indirizzo IP.
Se un sito a volte “non risolve”, il DNS è un sospetto comune—specialmente se fallisce su una rete/dispositivo ma funziona su un altro.
La cache è quando il browser salva copie delle risorse scaricate in precedenza per caricare più velocemente le visite successive.
Implicazioni pratiche:
I server controllano gran parte del comportamento di caching tramite header HTTP (come la durata della cache e la revalidazione).
HTTPS cifra il traffico e aiuta a garantire che tu sia connesso al dominio previsto, proteggendo login, form e dati sensibili in transito.
Non garantisce però che il sito sia affidabile o onesto. Devi comunque valutare:
example.com) — quale server/products/shoes) — quale risorsa?color=black) — parametri aggiuntivi#reviews) — una posizione all'interno della pagina (gestita dal browser)