Archiviare i dati su un server Web IoT utilizzando richieste HTTP POST

Come spiegato nel primo articolo della serie archiviare i dati ottenuti dai dispositivi Internet of Things, sebbene i dati salvati finiscano su un server MySQL o MariaDB e viene utilizzata la lingua PHP per manipolarli in input e in output, il flusso di informazioni tra le apparecchiature elettroniche e il database avviene utilizzando a server web con cui comunichi secondo il Protocollo HTTP.

All'inizio della definizione di Protocollo HTTP Ci sono stati utilizzi paragonabili a quello descritto ma il fatto è che alla fine non è stato sfruttato appieno per vari motivi, un po' di sicurezza un po' perché non si è mai fatto alcun passo avanti nella definizione di un protocollo più specifico e più efficiente, quindi oggigiorno, soprattutto nei server pubblici, la cosa più comune è utilizzare una connessione HTTP cosa rende a Richiesta POST al server per memorizzare le informazioni o a GET per recuperarlo, normalmente per visualizzare una pagina web che lo presenta e anche sulla quale è possibile interagire.

Il testo più semplice inviato al server in una richiesta HTTP POST include una riga con il tipo di richiesta (POST) il percorso della pagina web che memorizzerà le informazioni e la versione del file Protocollo HTTP; un'altra riga con il nome host (che ammette server virtuali sullo stesso server e/o sullo stesso indirizzo IP) ed infine un'altra che contiene i dati che vengono registrati, separati tra loro dal segno & e dalle righe precedenti da uno vuoto.

Nell'esempio sopra, un server chiamato polaridad.es conterrebbe una pagina in /iot/grabar_temperatura per gestire le informazioni utilizzando la versione 1.1 del Protocollo HTTP

Si può vedere che vengono utilizzati due segni & che indicano che sono memorizzati tre campi. Il nome dei campi è a sinistra del segno uguale e per definirli sono state utilizzate solo due lettere. Come il nome dei campi (o delle variabili, se preferisci) della richiesta HTTP Non hanno alcuna relazione con quelli presenti nel database, non è particolarmente importante utilizzare testi descrittivi e solitamente si scelgono nomi brevi (anche campi numerati) per salvare il testo in comunicazione con il server e velocizzare il processo di invio dei dati.

I dati che un dispositivo IoT invia normalmente al server sono di tipo numerico, prevalentemente numeri interi e decimali semplici. Quando i valori vengono inviati in formato testo, come nel caso della variabile "ne" nell'esempio, possono verificarsi circostanze sfavorevoli che possono essere risolte, a seconda dei casi, con più o meno successo e facilità. In questa occasione, i segni più (+) vengono utilizzati per separare le parole, sostituendo gli spazi che altrimenti altererebbero il Richiesta POST. Un modo generico di invio dati che risolve la maggior parte dei casi è indicando il codice esadecimale dei caratteri, preceduto dal segno di percentuale (%) Logicamente non è consigliabile utilizzare questa risorsa tranne quando ciò che è codificato è problematico poiché La lunghezza di cosa viene inviato viene aumentato, il che richiede generalmente più risorse, anche se è sicuramente di dimensioni molto ridotte.

Sebbene sia possibile utilizzare a server web Per l'Internet of Things solo con le informazioni dell'esempio precedente molti server, soprattutto quelli pubblici, aggiungono altri dati alla query POST (purtroppo non sempre limitata al protocollo). L'esempio seguente corrisponde alla post request richiesta dal pozzo -server noto pubblico per Internet delle cose CosaParla.

Oltre ad alcuni dati personali, come ad es X-THINGSPEAKAPIKEY (e che corrisponde all'identificativo di ciascun client) nell'esempio precedente puoi vedere che ci sono altre intestazioni che aggiungono ulteriori informazioni alla richiesta.

Come utilizzare un'intestazione in a Richiesta POST Consiste semplicemente nello scrivere il suo nome, i due punti (:), uno spazio vuoto e il valore che si desidera assegnargli.

Per testare le richieste POST al server web prima di completare la configurazione degli altri componenti, è possibile stabilire una connessione al server e inviare manualmente i dati. Ad esempio, su un computer Linux sarebbe sufficiente utilizzare telnet polaridad.es 80 dove polaridad.es è il nome del server e 80 è il numero di porta su cui risponde il servizio. HTTP.

Lo strumento multipiattaforma può essere utilizzato su Linux, Windows o sistema operativo PuTTY, di cui si parlava nell'articolo controllare i dispositivi seriali UART dal computer, per effettuare la connessione senza utilizzare la console.

Nel prossimo Elenco intestazioni HTTP Ci sono la maggior parte di quelli che possono essere utili per a Richiesta POST a server web per l'Internet delle cose.

• Accept Si usa per indicare la tipologia MIMO che la richiesta si aspetta che il server utilizzi nella risposta. È espresso come tipo/subtipo che può essere generalizzato utilizzando l'asterisco (*) come segno jolly, ad esempio as */* fare riferimento a qualsiasi o tipo/* per riferirsi a tutti i sottotipi di tipo

  I più comunemente usati sono:

  • text/plain Sebbene sia il più basilare, è anche il più utilizzato. Si prevede che il server restituisca una risposta di testo semplice (in chiaro), sufficiente ad avvisare che la transazione è stata corretta e al massimo aggiungere informazioni accessorie come il numero d'ordine dei dati registrati, il risultato di un confronto, la data della transazione server…

  • application/xml o text/xml Attendi che il server risponda alla richiesta in formato XML. Il significato di scegliere text al posto di application consente una lettura “umana” più semplice (rispetto a quella “automatica”). Questa dualità si presenterà negli altri Tipi MIME ma la tendenza futura dello standard è quella da preferire application contro text Il formato XML consente di strutturare una risposta che contiene molti dati in modo molto solido, lo svantaggio è che aggiunge molti artifici ai dati di rete, il che fa sì che la risposta occupi più del necessario, richiedendo quindi più larghezza di banda e probabilmente più memoria nel dispositivo IoT per elaborarlo.

  • text/html Utilizzato quando la risposta del server è HTML codificato come testo semplice (testo semplice) che solitamente formatta una risposta. Poiché si tratta di archiviare dati e la risposta raggiungerebbe un piccolo dispositivo senza molte risorse, non è comune utilizzare questo tipo.

  • application/xhtml+xml Fondamentalmente è la versione XHTML (HTML come XML valido) delle informazioni della sezione precedente.

  • application/json Viene utilizzato soprattutto quando la risposta del server contiene diversi dati inclusa una struttura più o meno complessa. Il formato JSON condividere con il formato XML una struttura solida e aggiunge il vantaggio di essere più concisi nel testo aggiunto dalla struttura.

• Accept-Charset Determina la codifica del testo che deve essere utilizzata nella risposta. Per codificare i caratteri latini, il UTF-8, il più completo, ISO-8859 15, che comprende il simbolo dell'Euro (€) e il ISO-8859 1, che è il più elementare.

• Accept-Encoding Indica il formato in base al quale può essere codificata la risposta del server. Fondamentalmente serve ad indicare un tipo di compressione. Alcuni dei più frequenti sono gzip deflate (che può essere specificato più dettagliatamente con deflate-raw o deflate-http) Non è comune utilizzarlo in piccoli dispositivi connessi all'Internet delle cose poiché richiede un certo consumo di risorse (memoria e tempo di elaborazione) che solitamente sono scarse in questo tipo di apparecchiature. Non è necessario indicare che non viene utilizzata la compressione Accept-Encoding: identity poiché tale circostanza è considerata per impostazione predefinita.

• Accept-Language Esprime la lingua che può essere utilizzata nella risposta. Ad esempio, lo spagnolo di Spagna verrebbe specificato come es-ES o l'inglese degli Stati Uniti d'America come en-US

• Connection Viene utilizzato per specificare cosa si deve fare con la connessione che è stata stabilita tra il client (il dispositivo IoT) e il server web una volta ricevuti i dati. Solitamente utilizzato con il valore close nel formato Connection: close per indicare che la connessione deve essere chiusa dopo aver risposto al client.

• Content-Length Permette di indicare il numero di byte occupati dalla parte della richiesta che contiene i dati, ovvero quella dopo le intestazioni e separata da una riga vuota. È molto utile poiché serve a verificare l'integrità delle informazioni che vengono inviate; Se non misura quanto dichiarato non viene memorizzato poiché si ritiene non sia arrivato correttamente. Di solito è richiesto dalla maggior parte dei server IoT pubblici.

• Content-Type Serve per indicare il Tipo MIME con cui sono codificate le informazioni inviate al server. I tipi vengono solitamente utilizzati text/html quando i dati inviati al server sono espressi come un semplice elenco di valori (qualcosa come a=3.6&b=4.8) Y application/jsonrequest (che sarebbe l'equivalente del tipo application/json di cui si parla in Accept) quando è necessaria una struttura più complessa, ma è possibile inviare uno qualsiasi dei seguenti elenco dei tipi MIME.

• Cookie Serve per aggiungere un identificatore di sessione con cui mantenere una catena di trasferimenti (query, risposta, query...) più complessa di una singola richiesta con cui inviare determinati dati correlati ma ottenuti in momenti diversi.

Sommario


• Referer URL che ha originato la richiesta POST, ad esempio la pagina web da cui è stata inviata. Nel caso di utilizzo per l'IoT, non aggiunge informazioni rilevanti poiché le informazioni vengono inviate direttamente, senza una pagina precedente, quindi non vengono utilizzate frequentemente.

• User-Agent Segnala il dispositivo che effettua la richiesta. Nel normale traffico web, il browser utilizzato nell'Internet delle cose consente al server di indicare il tipo di dispositivo elettronico che effettua la richiesta. L'identificazione con il server consente di formattare la risposta in modo diverso in ciascun caso, ad esempio restituendo una pagina Web complessa a un browser e alcuni dati di avviso a un piccolo dispositivo IoT.

È possibile specificare un elenco di opzioni separate da virgole invece di un singolo valore nelle intestazioni per indicare che sono supportati più valori diversi contemporaneamente. Questi valori possono avere un ordine di priorità che viene espresso secondo un coefficiente di qualità q per ciascuno. I coefficienti di qualità sono separati da un punto e virgola (;) e gli asterischi (*) possono anche essere utilizzati per riferirsi a qualsiasi tipo o sottotipo.

Accept: text/plain,text/xml,application/json;q=0.8,text/*;q=0.9,application/json

Nell'esempio precedente la priorità del formato JSON il maggiore (0.9) è quello del testo semplice e quello del testo formattato. XML, che soddisfano le specifiche text/*, è minore (0.8) e uguale tra loro. Se possibile, il server dovrebbe reagire codificando la risposta come JSON.

Nel seguente esempio di richiesta POST più completa, si accede alla pagina /iot/grabar_temperatura del server chiamato polaridad.es utilizzando la versione 1.1 del protocollo HTTP. Il client, chiamato Sensoreitor-2000, invia i dati codificati JSON, aspettati che la risposta sia in formato testo normale UTF-8 usando lo spagnolo dalla Spagna senza usare la compressione, che, tra l'altro, non è necessario indicare. I dati inviati al server occupano 65 byte. Quando si invia la risposta, la connessione tra il client e il server verrà chiusa.

Il seguente articolo spiega come configurare il database MySQL per archiviare le informazioni inviate dagli oggetti IoT