In questo articolo illustrerò i concetti di Request e Response nella comunicazione di rete, in particolare nel protocollo HTTP. Vuole essere un articolo divulgativo e non esaustivo, per cui alcuni concetti saranno semplificati per aiutare la comprensione. L’articolo è pensato per essere un supporto alle mie lezioni, ma può essere letto e compreso anche senza di esse. Buona lettura!
Quando andiamo a visitare un qualsiasi sito web, per esempio digitiamo l’indirizzo: “www.ansa.it” nel nostro browser si dice che viene generata unaRequest dal nostro computer verso il server di competenza, in questo caso: ansa.it. Più precisamente, a rispondere saranno i computer del Provider presso il quale l’agenzia ANSA ha registrato il proprio sito web, ma ai fini di questo articolo possiamo immaginare il server come un semplice computer qualsiasi che rimane in perenne ascolto di tutte le Request indirizzate verso di lui.
Il Server quindi riceve la Request, la elabora, e produce una Response in risposta. Tipicamente, la Response contiene la Web Page da visualizzare, che sarà elaborata dal nostro browser.
Dal punto di vista della programmazione ad oggetti, Request e Response sono appunto due oggetti, due “cose” dotate di determinate caratteristiche: esse sono molto simili fra loro e sono entrambe composte da due “sezioni” distinte: Header e Body.
l’Header contiene meta-dati quali l’URL, il method (vedremo più avanti cosa sono), l’indirizzo IP del chiamante, il nome del Browser che ha effettuato la request, il tipo di dati contenuti nel corpo, e così via. Il Body, come si può immaginare, contiene i dati veri e propri: il corpo della trasmissione.
Torniamo al nostro esempio e immaginiamo quindi di aver indirizzato la nostra request al server ansa.it: il Server, come detto sopra, elabora la richiesta e produce la response. In questo caso ci restituirà l’HTML della home page del sito da visualizzare.
L’HTML è un linguaggio a marcatori e non è un linguaggio di programmazione. Tuttavia, possiamo impropriamente dire che esso contiene le istruzioni che permettono al nostro browser di visualizzare una pagina Web e può contenere riferimenti a moltissime risorse di rete (immagini, icone, video, scripts, ecc) che vengono scaricate ordinatamente eseguendo per ciascuna un’opportuna nuova request.
La Response che viene restituita potrebbe essere una risorsa statica (cioè un file da leggere e riportare nel body così com’è) o una risorsa dinamica, ovvero una risposta (una pagina) creata ad hoc a seconda delle esigenze del chiamante o, per meglio dire, secondo i parametri che quest’ultimo ha espresso nella Request.
I parametri
Già, qui sta il bello: la Request può avere dei parametri. Qualcosa come show=products o limit=10 per indicare che su una certa pagina vogliamo vengano mostrati prodotti o vogliamo limitare la visualizzazione alle prime 10 righe. I parametri sono sempre coppie chiave=valore e se ce n’è più di uno sono legati fra loro dal simbolo & (e commerciale). Non sono ammessi spazi bianchi nei parametri, né nel nome né nei valori. Se dovessero trovarsi degli spazi bianchi o altri caratteri non permessi essi saranno codificati secondo la codifica HTML. Per cui, per esempio, il parametro nome=Mario Rossi sarà codificato in nome=Mario%20Rossi.
Facciamo un esempio: per visualizzare i primi 10 prodotti di un mercatino online potremmo generare una request con il seguente URL:
www.mercatoonline.it?show=products&limit=10
La request arriverà ai server di mercatoonline.it e un apposito programma sul server (il Web Server, appunto) si occuperà di gestire la richiesta, ne leggerà i parametri e, attraverso l’esecuzione di un particolare linguaggio di programmazione (PHP, Java o altro), restituirà l’opportuna response. Questo è un esempio di pagina dinamica.
Il Web Application Server è un programma che rimane in ascolto di request sulla rete e produce la response adeguata usando uno dei linguaggi indicati (o addirittura altri che non ho nemmeno citato). Il concetto importante che voglio spiegare qui è che ogni web-server dinamico usa un linguaggio di programmazione per produrre le response. Un linguaggio di programmazione vero, non HTML ;).
Questa parte è quella che in gergo viene chiamata back-end: è quello che sta dietro a un sito web, quello che l’utente finale non vede. In contrapposizione, il front-end è invece tutto quello che arriva al browser e di cui l’utente finale ha un’esperienza diretta.
Ho semplificato un po’ la parte dei parametri, perché in verità esistono anche altri modi in cui una request può presentare i suoi parametri, ma quello che ho illustrato è il metodo standard, il più semplice ed è propedeutico per comprendere gli altri, che spiegherò negli articoli successivi.
I programmatori che lavorano sul back end, quindi, lavorano con un Web Application Server e sono chiamati a scrivere gli algoritmi che permettano ad ogni Request di avere la sua Response.
Se avete studiato un po’ di programmazione, probabilmente sarete abituati all’idea di avere un punto di ingresso del codice e un punto finale. Sarete abituati all’idea che un programma viene lanciato su un sistema operativo e su di esso si basa, interrogandolo quando ne ha bisogno (per esempio quando deve leggere o scrivere un file). Quando si lavora su un Web Application Server le cose sono un po’ diverse: non esiste un punto di ingresso, poiché ogni request è un punto di ingresso. Gli algoritmi non vengono eseguiti dal sistema operativo, ma dal Web Application Server, quindi “vivono” in un contesto che è non è il sistema operativo, ma si appoggia a sua volta su di esso. Il contesto (il Web Application Server) può essere configurato secondo i bisogni, poiché non è altro che un “normale” programma.
Generare una Request
Come si può generare una request? Esistono diversi modi di farlo ed esistono diverse modi in cui una request porta i suoi parametri al server. Questi modi dipendono da un parametro detto method e qui potete trovare una breve spiegazione su cosa sia. Altrimenti potete continuare a leggere, ignorando (per ora!) il concetto di method. In breve, ecco come generare una Request:
- Digitando un indirizzo sulla barra del browser. In questo caso la Request generata è sempre in method GET.
- Inviando una form da una pagina web. In questo caso il method della Request dipende dal method impostato nello specifico attributo della form.
- Generando una request con un linguaggio di programmazione, tipicamente Javascript. Tuttavia, tutti i linguaggi di programmazione hanno metodi per generare Request. Anche in questo caso il method della Request dipende dalle impostazioni con la quale viene creata.
Gli stati della Response
Come ho detto sopra ogni Response (ma anche ogni Request) ha un header che contiene dei meta-dati. Fra questi un meta-dato importante è lo stato, che ci da informazioni circa la comunicazione Request/Response.
Se la comunicazione è andata a buon fine e la Response è stata prodotta correttamente allora si otterrà lo status OK, corrispondente al numero 200. Ogni stato è infatti associato ad un numero e un messaggio. Tutti i numeri diversi da 200 rappresentano degli errori e a numero diverso corrisponde errore diverso. Ecco di seguito i più comuni e importanti:
- 200: OK. Comunicazione a buon fine
- 301: Moved Permanently. La risorsa richiesta è stata spostata su un altro indirizzo. Di solito segue redirect al nuovo indirizzo con produzione di una nuova Request.
- 401: Unauthorized. Il client non ha l’autorizzazione necessaria per accedere alla risorsa richiesta
- 403: Forbidden. La richiesta è legittima ma il server si rifiuta di soddisfarla per qualche ragione (diversa da 401).
- 404: Not Found. La risorsa richiesta non è stata trovata.
- 500: Internal Server Error. Messaggio generico per indicare un errore lato server.
Tornerò su questi argomenti nelle lezioni successive, approfondendoli, ma per ora è tutto. Buono studio e grazie per l’attenzione!