DAY 2

CRONACA DI PROGETTO 

DAY 2 

About HTTP

La mattina del secondo giorno di corso si apre con una lezione dettagliata sul protocollo HTTP, tenuta come sempre dal nostro eccellente tutor, Antonio Pintus. Per capire meglio cosa rappresenti questo particolare nome proviamo a immaginare di dover scrivere una lettera formale ad una persona importante. Nella stesura della lettera si rivelerà opportuno l'utilizzo di una certa forma, ad esempio inserire oltre al messaggio la data, l'indirizzo del destinatario, la firma e così via. Allo stesso modo, quando due dispositivi comunicano attraverso il protocollo HTTP devono utilizzare delle particolari forme di "scrittura" del messaggio. E' importante sottolineare che la comunicazione con protocollo HTTP prevede solo l'interazione tra due dispositivi del tipo "request-response", ovvero richiesta e risposta. Di fatto, in un dialogo c'è sempre un dispositivo che chiede e l'altro che risponde. E sebbene le richieste e le risposte possano essere di vario tipo, la loro forma rimane sempre la stessa, e sarà questo ciò che vi illustreremo.

La strutta del protocollo HTTP è divisa in tre parti. La prima, detta "request-line"  indica il tipo richiesta che stiamo facendo. Nel caso in cui ricevessimo una risposta da un server questa prima parte prende il nome di "status line" poiché come suggerisce il nome stesso ci informa sullo stato della comunicazione. Se quest'ultima fosse il paziente di un dottore la status line sarebbe il suo referto medico. Grazie alla status line e ad un messaggio a tre cifre contenuto in essa siamo in grado di capire se il server destinatario della nostra richiesta l'abbia effettivamente ricevuta, accettata o ci abbia ad esempio negato i permessi per accedere a un contenuto che volevamo. Oltre alla status line il protocollo HTTP prevede anche una seconda parte, quella degli header. Così come ognuno di noi è in possesso del proprio documento d'identità dove vengono specificati indirizzo, data di nascita e altri dati personali, così gli header informano i dispositivi su molti dettagli aggiuntivi al semplice stato della comunicazione. Con gli header possiamo informarci sul tipo di messaggio che stiamo ricevendo, sulla dimensione suo contenuto o al contrario possiamo chiedere di ricevere solo un certo tipo di contenuti creati in una precisa data. Ci accingiamo ora ad arrivare all'ultima parte del protocollo HTTP, quella che trasporta il vero e proprio contenuto della richiesta e della risposta. Questa è detta anche "body" perché in essa è impacchettato il contenuto del messaggio, esattamente come quando scriviamo ciò che l'altra persona dovrà leggere nella parte sinistra di una cartolina.

Sebbene la struttura che abbiamo appena analizzato rimanga invariata per tutte le comunicazione che utilizzano il protocollo HTTP, i contenuti di queste ultime possono variare in tanti fattori. Diversi sono infatti i tipi di richieste che possiamo inviare; le due su cui ci concentriamo di più e che più hanno da aggiungere al nostro bagaglio IoT sono quelle di GET e di POST. La prima richiede un contenuto, la seconda chiede di postarlo sul server. Com'è facile intendere, in un ipotetico sistema "sensore-server-attuatore" le richieste GET e POST sono quelle che comporrebbero la fitta rete di messaggi, poiché dove il sensore chiede di inserire dati sul server, l'attuatore chiede di riceverli da esso.

GET e POST in Arduino

Dopo aver capito di più sulle comunicazioni HTTP arriva il momento di applicare gli insegnamenti del nostro tutor su qualcosa di tangibile. Decidiamo quindi di provare le due funzioni di GET e POST mediante il nostro Arduino Yùn. Come ogni comando che impartiamo alla scheda dev'essere prima programmato con uno sketch, anche le funzioni  sopracitate sono utilizzabili solo se prima programmate nella scheda. Per permettere al nostro processore di comunicare con un altro dispositivo è necessario impostarlo per connetterlo autonomamente a una rete. Per chi volesse cimentarsi nell'impresa le procedure (abbastanza elementari) sono descritte in questa guida
Ora che la nostra scheda è connessa alla rete tentiamo di fare una richiesta GET ad un indirizzo dato e ne analizziamo i risultati. Ancora una volta, per chiunque volesse ripetere la procedura le indicazioni possono essere trovate seguendo questo link noi invece vi riportiamo solo una parte "saliente" dello sketch dove è chiaramente visibile il tipo di richiesta "client.get" 

            

A seguito della richiesta riceveremo una risposta che Arduino stamperà sul monitor seriale e che potremo quindi visualizzare agevolmente.

Fatto ciò ci inoltriamo più in là nelle acque della comunicazione e proviamo la seconda delle due funzioni che vi abbiamo presentato, quella di POST. Per chiedere di caricare un contenuto dobbiamo ovviamente avere qualcosa da inviare e per questo decidiamo di rilevare la temperatura con il circuito sperimentato nel DAY 1 e di spedire i valori letti dal nostro Arduino a un server di prova (generato sul sito www.requestb.in). Come nel caso precedente vi riproponiamo solo la parte più "saliente" dello sketch, quella dove è visualizzato il comando POST e l'indirizzo del server a cui invieremo il nostro dato. 

Fatto ciò ci sarà possibile accedere al dato caricato ogni qualvolta vorremo, o in un contesto più concreto, ogni qualvolta il nostro attuatore avrà bisogno di un valore su cui basarsi.