Stocați date pe un server web IoT utilizând solicitări HTTP POST

După cum este explicat în primul articol al seriei stocați datele obținute de dispozitivele Internet of Things, deși datele care sunt salvate ajung pe un server MySQL o MariaDB iar limbajul este folosit PHP pentru a le manipula la intrare și la ieșire, fluxul de informații între echipamentul electronic și baza de date are loc folosind a server web cu care comunici conform Protocolul HTTP.

La începutul definiţiei lui Protocolul HTTP Au existat utilizări comparabile cu cea descrisă, dar adevărul este că până la urmă nu a fost exploatat pe deplin din diverse motive, parțial securitate și parțial pentru că nu s-au făcut niciodată progrese în definirea unui protocol mai specific sau mai eficient, așa că în prezent, mai ales în serverele publice, cel mai obișnuit lucru este să folosești o conexiune HTTP ce face o Solicitare POST către server pentru a stoca informațiile sau a GET pentru a-l recupera, in mod normal pentru a afisa o pagina web care il prezinta si chiar pe care sa interactionezi.

Cel mai elementar text trimis către server într-o solicitare HTTP POST include o linie cu tipul cererii (POST) calea către pagina web care va stoca informațiile și versiunea Protocolul HTTP; o alta linie cu numele gazda (care permite servere virtuale pe acelasi server si/sau pe aceeasi adresa IP) si in final o alta care contine datele care sunt inregistrate, separate intre ele prin semnul & si de randurile anterioare printr-un gol.

În exemplul de mai sus, un server numit polaridad.es ar conține o pagină în /iot/grabar_temperatura pentru a gestiona informațiile folosind versiunea 1.1 a Protocolul HTTP

Se poate observa că sunt folosite două și semne care arată că sunt stocate trei câmpuri. Numele câmpurilor este în stânga semnului egal și au fost folosite doar două litere pentru a le defini. Ca numele câmpurilor (sau variabilelor, dacă preferați) cererii HTTP Nu au legătură cu cele din baza de date, nu este deosebit de importantă folosirea textelor descriptive și de obicei se aleg nume scurte (chiar și câmpuri numerotate par) pentru a salva textul în comunicarea cu serverul și a grăbi procesul de trimitere a datelor.

Datele pe care un dispozitiv IoT le trimite în mod normal către server sunt de tip numeric, în principal numere întregi și zecimale simple. Atunci când valorile sunt trimise în format text, așa cum este cazul variabilei „ne” din exemplu, pot apărea circumstanțe nefavorabile care pot fi rezolvate, în funcție de caz, cu mai mult sau mai puțin succes și ușurință. Cu această ocazie, semnele plus (+) sunt folosite pentru a separa cuvintele, înlocuind spațiile care altfel ar modifica Solicitare POST. O modalitate generică de trimitere a datelor care rezolvă cele mai multe cazuri este prin indicarea codului hexazecimal al caracterelor, precedat de semnul procentual (%) În mod logic, nu este recomandabil să folosiți această resursă decât atunci când ceea ce este codificat este problematic deoarece Lungimea de se mărește ceea ce se trimite, ceea ce necesită, în general, mai multe resurse, deși cu siguranță este de dimensiuni foarte mici.

Deși este posibil să se opereze a server web Pentru internetul lucrurilor doar cu informațiile din exemplul anterior, multe servere, în special cele publice, adaugă alte date la interogarea POST (din păcate nu se limitează întotdeauna la protocol).Exemplul de mai jos corespunde solicitării post solicitate de sondă. -server cunoscut.public pentru internetul lucrurilor ThingSpeak.

Pe lângă unele date personale, cum ar fi X-THINGSPEAKAPIKEY (și care corespunde cu identificatorul fiecărui client) în exemplul anterior se poate observa că există și alte anteturi care adaugă mai multe informații la cerere.

Cum se folosește un antet într-un Solicitare POST Constă pur și simplu în scrierea numelui, a unui semn de două puncte (:), a unui spațiu liber și a valorii pe care doriți să i-o atribuiți.

Pentru a testa cererile POST către serverul web înainte de a finaliza configurarea celorlalte componente, se poate stabili o conexiune la server și datele se pot trimite manual. De exemplu, pe un computer Linux ar fi suficient de utilizat telnet polaridad.es 80 unde polaridad.es este numele serverului și 80 este numărul portului la care răspunde serviciul. HTTP.

Instrumentul multiplatform poate fi utilizat pe Linux, Windows sau OS PuTTY, despre care s-a vorbit în articol controlați dispozitivele seriale UART de pe computer, pentru a realiza conexiunea fără a utiliza consola.

În urmatoarele Lista antetelor HTTP Există majoritatea celor care pot fi utile pentru a Solicitare POST la server web pentru Internetul lucrurilor.

• Accept Este folosit pentru a indica tipul MIMA pe care cererea se așteaptă ca serverul să îl folosească în răspuns. Se exprimă ca tipo/subtipo care poate fi generalizat folosind asteriscul (*) ca semn de wildcard, de exemplu ca */* a se referi la oricare sau tipo/* pentru a se referi la toate subtipurile de tipo

  Cele mai frecvent utilizate sunt:

  • text/plain Deși este cel mai elementar, este și cel mai folosit. Se așteaptă ca serverul să returneze un răspuns text simplu (plat) care este suficient pentru a anunța că tranzacția a fost corectă și cel mult să adauge informații accesorii, cum ar fi numărul de comandă al datelor înregistrate, rezultatul unei comparații, data Server…

  • application/xml o text/xml Așteptați ca serverul să răspundă la cerere în format XML. Sensul alegerii text în loc de application permite o citire mai ușoară „umană” (versus „automată”). Această dualitate se va prezenta în alții tipuri MIME dar tendința viitoare a standardului este de a prefera application în fața text Formatul XML permite ca un răspuns care conține multe date să fie structurat într-un mod foarte solid, dezavantajul este că adaugă mult artificiu datelor de pe net, ceea ce face ca răspunsul să ocupe mai mult decât este necesar, prin urmare necesită mai multă lățime de bandă și probabil mai mult memorie în dispozitivul IoT pentru a o procesa.

  • text/html Folosit atunci când răspunsul serverului este HTML codificat ca text simplu (text simplu) formatând de obicei un răspuns. Deoarece este vorba despre stocarea datelor și răspunsul ar ajunge la un dispozitiv mic, fără multe resurse, nu este obișnuit să folosiți acest tip.

  • application/xhtml+xml Practic este varianta XHTML (HTML ca XML valabil) a informațiilor din secțiunea precedentă.

  • application/json Este cel mai utilizat atunci când răspunsul serverului conține mai multe date, inclusiv o structură mai mult sau mai puțin complexă. Formatul JSON partajați cu format XML o structură solidă și adaugă avantajul de a fi mai concis în textul adăugat de structură.

• Accept-Charset Determină codarea textului care se solicită să fie utilizată în răspuns. Pentru a codifica caracterele latine, UTF-8, cel mai complet, ISO-8859 15, care include semnul euro (€) și ISO-8859 1, care este cel mai elementar.

• Accept-Encoding Indică formatul după care răspunsul serverului poate fi codificat. Practic servește pentru a indica un tip de compresie. Unele dintre cele mai frecvente sunt gzip deflate (care poate fi specificat mai detaliat cu deflate-raw o deflate-http) Nu este obișnuită să-l folosești în dispozitivele mici conectate la Internet of Things, deoarece necesită un anumit consum de resurse (memorie și timp de procesare) care sunt de obicei rare la aceste tipuri de echipamente. Nu este necesar să indicați că compresia nu este utilizată cu Accept-Encoding: identity întrucât o asemenea împrejurare este considerată implicit.

• Accept-Language Exprimă limbajul care poate fi folosit în răspuns. De exemplu, spaniola din Spania ar fi specificată ca es-ES sau englezii Statelor Unite ale Americii ca en-US

• Connection Este folosit pentru a specifica ce trebuie făcut cu conexiunea care a fost stabilită între client (dispozitivul IoT) și server web odată ce datele sunt primite. Utilizat de obicei cu valoarea close în format Connection: close pentru a indica faptul că conexiunea ar trebui să fie închisă după ce a răspuns clientului.

• Content-Length Vă permite să indicați numărul de octeți ocupați de partea din cerere care conține datele, care este cea de după anteturi și separați printr-o linie goală. Este foarte util deoarece servește la verificarea integrității informațiilor care sunt trimise; Daca nu masoara ceea ce s-a declarat, nu este stocat deoarece se considera ca nu a ajuns corect. De obicei, este cerut de majoritatea serverelor IoT publice.

• Content-Type Servește pentru a indica Tip MIME cu care se codifică informațiile trimise către server. Tipurile sunt de obicei folosite text/html atunci când datele trimise către server sunt exprimate ca o simplă listă de valori (ceva de genul a=3.6&b=4.8) Y application/jsonrequest (care ar fi echivalentul tipului application/json despre care se vorbeste in Accept) când este necesară o structură mai complexă, dar oricare dintre următoarele pot fi trimise lista de tipuri MIME.

• Cookie Este folosit pentru a adăuga un identificator de sesiune cu care să mențină un lanț de transferuri (interogare, răspuns, interogare...) care este mai complex decât o singură solicitare cu care să trimită anumite date conexe dar obținute în momente diferite.

Cuprins


• Referer Adresa URL care a generat solicitarea POST, de exemplu pagina web de pe care a fost trimisă. În cazul în care este utilizat pentru IoT, nu adaugă informații relevante deoarece informația este trimisă direct, fără o pagină anterioară, deci nu este folosită frecvent.

• User-Agent Raportează dispozitivul care face cererea. În traficul web normal, browserul utilizat în Internet of Things permite serverului să indice tipul de dispozitiv electronic care face cererea. Identificarea pe server permite ca răspunsul să fie formatat diferit în fiecare caz, de exemplu, returnând o pagină web complexă la un browser și câteva date de avertizare la un dispozitiv IoT mic.

Este posibil să specificați o listă de opțiuni separate prin virgulă în loc de o singură valoare în anteturi pentru a indica faptul că mai multe valori diferite sunt acceptate simultan. Aceste valori pot avea o ordine de prioritate care se exprimă în funcție de un coeficient de calitate q pentru fiecare. Coeficienții de calitate sunt separați prin punct și virgulă (;) și asteriscurile (*) pot fi, de asemenea, folosite pentru a se referi la orice tip sau subtip.

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

În exemplul anterior prioritatea formatului JSON cel mai mare (0.9) este cel al textului simplu și cel al textului formatat. XML, care îndeplinesc specificația text/*, este mai mic (0.8) și egal între ele. Dacă este posibil, serverul ar trebui să reacționeze prin codificarea răspunsului ca JSON.

În următorul exemplu de solicitare POST mai completă, pagina /iot/grabar_temperatura a serverului numit polaridad.es este accesată utilizând versiunea 1.1 a protocolului HTTP. Clientul, numit Sensoreitor-2000, trimite datele codificate în JSON, așteptați răspunsul ca text simplu în format UTF-8 folosind spaniola din Spania fără a folosi compresia, ceea ce, apropo, nu este necesar să o indicați. Datele trimise către server ocupă 65 de octeți. La trimiterea răspunsului, conexiunea dintre client și server va fi închisă.

Următorul articol explică cum să configurați baza de date MySQL pentru a stoca informațiile trimise de obiectele IoT