Web e protocolli

Ogni volta che aprite un sito, il browser e il server si scambiano messaggi seguendo regole precise. In questo modulo vediamo quali sono queste regole e come sono organizzate — le stesse che state usando scrivendo le vostre applicazioni Flask in laboratorio.

1.1 Cos'è un'architettura REST

REST (Representational State Transfer) non è un linguaggio o una tecnologia: è un insieme di regole che molti siti e applicazioni web seguono per organizzarsi in modo semplice e prevedibile. Quando scrivete una API con Flask, di fatto state già seguendo (almeno in parte) queste regole.

Le idee principali sono poche e intuitive:

• Client e server separati. Chi chiede i dati (es. il browser, un'app) e chi li fornisce (il server) sono due parti indipendenti: si può cambiare l'uno senza toccare l'altro, purché restino d'accordo su come parlarsi.
• Nessuna memoria tra una richiesta e l'altra (stateless). Il server non "ricorda" chi siete da una richiesta all'altra: ogni richiesta deve contenere tutte le informazioni necessarie (es. un token di accesso). È per questo che servono meccanismi come i cookie o i token, che vedremo più avanti.
• Le risorse hanno un indirizzo. Ogni "cosa" gestita dal server (uno studente, un prodotto, un ordine) ha un proprio indirizzo (URL), es. /studenti/17.
• Si usano metodi standard per agire sulle risorse (li vedremo nel dettaglio nel punto 1.3): leggere, creare, modificare, cancellare.

Quando in laboratorio scrivete un endpoint Flask come @app.route('/prodotti/<id>'), quell'URL rappresenta esattamente il concetto di "risorsa con un indirizzo" di cui parla REST.

REST vs SOAP — SOAP è un altro modo, più vecchio e più rigido, di far comunicare due sistemi. Non serve conoscerlo in dettaglio, ma è utile sapere perché REST lo ha in gran parte sostituito:

	REST	SOAP
Formato dati	Di solito JSON (leggero)	Sempre XML (più "pesante")
Regole	Poche linee guida flessibili	Uno standard rigido e formale
Facilità d'uso	Semplice da leggere e testare	Richiede strumenti dedicati
Dove si usa oggi	Quasi ovunque (app, siti, IoT)	Sistemi bancari/aziendali datati

1.2 Il modello ISO/OSI e la pila TCP/IP

Quando due computer comunicano, in realtà stanno succedendo tante cose diverse allo stesso tempo: dai segnali elettrici nel cavo, fino al messaggio che vedete a schermo. Per non fare confusione, questo lavoro viene diviso in "livelli", ognuno con un compito preciso.

Il modello ISO/OSI è quello teorico, con 7 livelli. Nella pratica di internet si usa una versione più semplice, la pila TCP/IP, con 4 livelli:

• Applicazione — qui vivono i programmi che usate: browser, app di posta. È qui che si trova HTTP, il protocollo di cui parliamo nel prossimo punto.
• Trasporto — si occupa di far arrivare i dati in modo corretto (o veloce) da un programma all'altro. Qui vivono TCP (affidabile, controlla che tutto arrivi) e UDP (più veloce, meno controlli — quello usato nei giochi online o nello streaming).
• Internet/Rete — si occupa di far viaggiare i dati da un computer all'altro nel mondo, usando gli indirizzi IP.
• Accesso alla rete — la parte più "fisica": cavi, Wi-Fi, schede di rete.

Quando scrivete app.run(host="0.0.0.0", port=5000) in Flask, state lavorando al livello Applicazione. Sotto, in modo invisibile, TCP si occupa di consegnare in modo affidabile i pacchetti, e IP di instradarli fino al computer giusto.

Il punto da ricordare non sono i nomi dei livelli a memoria, ma il concetto: ogni livello si fida di quello sotto e non si preoccupa di come funziona. Per questo potete scrivere un'app web senza sapere nulla di cavi di rete.

1.3 Il protocollo HTTP nel dettaglio

HTTP è il linguaggio con cui browser e server si parlano. Ogni volta che caricate una pagina, il browser manda una richiesta e il server risponde con una risposta. Vediamo di cosa sono fatte.

I metodi — dicono al server cosa volete fare:

• GET — voglio leggere/ottenere qualcosa (es. caricare una pagina)
• POST — voglio creare qualcosa di nuovo (es. inviare un form)
• PUT — voglio modificare completamente qualcosa che esiste già
• DELETE — voglio eliminare qualcosa

Gli header — sono informazioni "di contorno" che accompagnano la richiesta o la risposta, senza far parte del contenuto vero e proprio. Un po' come i dati scritti fuori da una busta, prima ancora di aprirla.

Content-Type: application/json dice al destinatario "quello che trovi dentro è in formato JSON". User-Agent dice al server quale browser/dispositivo sta facendo la richiesta.

Gli status code — sono il "voto" che il server dà alla vostra richiesta, un numero a 3 cifre:

• 200 — tutto ok
• 404 — risorsa non trovata
• 500 — errore del server

La cache — è un modo per non dover richiedere ogni volta le stesse cose. Il server può dire al browser "questa immagine non cambierà per un'ora, tienila salvata" tramite l'header Cache-Control. Risultato: pagine più veloci e meno traffico di rete.

I cookie — dato che HTTP "non ricorda nulla" tra una richiesta e l'altra (lo stateless di cui parlavamo al punto 1.1), i cookie sono il modo con cui il server lascia un piccolo "bigliettino" nel browser, che verrà rimandato indietro a ogni richiesta successiva. È così che un sito "si ricorda" che siete loggati.

Attenzione: Un cookie mal protetto può essere rubato e usato per impersonare un utente. Ne riparleremo nel Modulo 2, quando parliamo di sicurezza delle applicazioni web.

Esercizi