Ciao, e benvenuto nella quinta puntata della quarantatreesima stagione. Nelle scorse puntate abbiamo costruito il meccanismo di REST: cose, indirizzi, pochi verbi. Oggi affrontiamo una regola che, la prima volta, suona strana, persino scomoda, ma che ha conseguenze profonde: il server non tiene memoria di te tra una richiesta e l'altra. Si chiama assenza di stato, e capirla svela perché REST regge il traffico del mondo. Oggi vediamo perché un servizio smemorato, per scelta, è più forte di uno che ricorda.
Partiamo dalla regola, così com'è, perché va detta chiara. In REST, ogni richiesta che fai deve contenere tutto ciò che serve per capirla, da sola, per intero. Chi sei, cosa vuoi: tutto dentro quella singola richiesta. Perché? Perché il server, dopo averti risposto, si dimentica di te. Non conserva il ricordo della tua richiesta precedente. La prossima volta che ti presenti, per lui sei un perfetto sconosciuto, e devi ripresentarti e rispiegare tutto da capo. È come parlare a uno sportello dove l'impiegato, tra un cliente e l'altro, perde completamente la memoria: ogni volta gli racconti tutto daccapo.
Voglio affrontare l'obiezione ovvia, perché la stai già pensando. A prima vista sembra una follia scomoda. Perché mai dovrei volere un servizio che si dimentica di me a ogni richiesta? Non sarebbe più comodo se ricordasse? La risposta è controintuitiva, e bellissima: quella smemoratezza compra una semplicità e una capacità di crescere enormi. Rinunciare alla memoria sul server non è una perdita: è ciò che permette al servizio di reggere quantità di traffico altrimenti impossibili. Ora ti spiego perché, ed è il cuore della puntata.
Voglio mostrarti il regalo della scalabilità, perché è la vera ragione. Se il server non ricorda niente di te tra una richiesta e l'altra, allora qualunque server può rispondere a qualunque tua richiesta. Non hai bisogno di tornare sempre dallo stesso: ne puoi mettere cento identici dietro le quinte, e ogni tua richiesta va a quello libero in quel momento, perché nessuno ha bisogno di averti già visto prima. Ricordi quando parlammo di distribuire il carico su tante macchine? Ecco: l'assenza di memoria è proprio ciò che lo rende possibile. Se ogni server dovesse ricordarsi i suoi clienti, dovresti sempre tornare da quello giusto, e non potresti spargere liberamente il lavoro. Smemorati, invece, sono tutti intercambiabili.
Voglio mostrarti il secondo regalo, la robustezza, perché è altrettanto prezioso. C'è un altro vantaggio: se un server si guasta nel mezzo, non si perde nessuna conversazione, perché non c'era nessuna conversazione in corso su di lui. Ogni richiesta era completa in sé, indipendente. Se cade, la richiesta successiva va semplicemente a un altro server, che la capisce lo stesso, perché contiene già tutto. Non c'è un filo del discorso da perdere, nessuna sessione fragile appoggiata su una singola macchina. La smemoratezza rende il sistema resistente: nulla di importante è mai in bilico su un solo server.
Voglio affrontare la domanda che sorge spontanea, perché è giusta e istruttiva. Ma un momento, dirai: i siti però si ricordano che ho fatto l'accesso, che sono io. Se il server è smemorato, dove vive quel ricordo? Ottima domanda, e la risposta è elegante. Il ricordo non sta nel server tra una richiesta e l'altra: sta in ciò che la richiesta porta con sé. Tu, a ogni richiesta, mostri di nuovo un tesserino che dice chi sei, e il server lo controlla ogni volta da capo, magari andando a leggere in una memoria condivisa e velocissima, come quella di cui parlammo tempo fa. Quindi assenza di stato non significa niente memoria da nessuna parte: significa niente memoria tenuta dal singolo server tra una richiesta e l'altra. Il cliente porta con sé la sua identità, ogni volta.
Voglio darti l'immagine che lega tutto, perché rende chiaro il compromesso. Pensa a uno sportello dove ogni impiegato perde la memoria tra un cliente e l'altro, ma dove tu porti sempre con te la tua cartella completa, e la mostri ogni volta. Per una persona sembrerebbe assurdo. Ma guarda il vantaggio: puoi andare da qualunque impiegato, non devi cercare quello che ti aveva già seguito, e se uno stacca, un altro ti serve identicamente, perché tutto ciò che serve è nella tua cartella, non nella sua testa. La scomodità apparente, ripresentarsi ogni volta, è esattamente ciò che rende il sistema flessibile e robusto.
Per oggi ci fermiamo qui. Abbiamo affrontato una regola strana di REST: il server non tiene memoria di te tra una richiesta e l'altra, e ogni richiesta deve contenere tutto ciò che serve, da sola. Sembra scomodo, ma quella smemoratezza è un superpotere: se nessun server deve averti già visto, qualunque server può servirti, e puoi spargere il carico su cento macchine intercambiabili; e se una cade, nessuna conversazione si perde. Il ricordo di chi sei non sparisce: viaggia con te, in un tesserino che mostri ogni volta, controllato magari in una memoria condivisa. La lezione: rendere ogni interazione completa in sé, invece che appoggiata a uno stato ricordato, è un potente motore di scala e robustezza. Nella prossima puntata vediamo il linguaggio delle risposte: i codici di stato. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.