Andmete salvestamine IoT veebiserverisse, kasutades HTTP POST-päringuid

Nagu sarja esimeses artiklis selgitatud salvestada asjade Interneti seadmete abil saadud andmeid, kuigi salvestatud andmed jõuavad serverisse MySQL o MariaDB ja keelt kasutatakse PHP nende manipuleerimiseks sisendis ja väljundis toimub teabevoog elektroonikaseadmete ja andmebaasi vahel, kasutades a veebiserver kellega suhtlete vastavalt HTTP protokoll.

Määratluse alguses HTTP protokoll Kasutati kirjeldatuga võrreldavaid kasutusviise, kuid tõsiasi on see, et lõpuks ei ole seda erinevatel põhjustel täielikult ära kasutatud, osaliselt turvalisuse ja osaliselt seetõttu, et konkreetsema või tõhusama protokolli määratlemisel pole kunagi edusamme tehtud, nii et tänapäeval on eriti oluline. avalikes serverites on kõige tavalisem ühenduse kasutamine HTTP mis teeb a POSTI taotlus serverisse teabe salvestamiseks või a GET selle taastamiseks, tavaliselt veebilehe kuvamiseks, mis seda esitleb ja millel saate isegi suhelda.

Kõige elementaarsem tekst, mis saadetakse serverile päringus HTTP POST sisaldab rida päringu tüübiga (POST) tee veebilehele, mis salvestab teavet ja versiooni HTTP protokoll; teine ​​rida hostinimega (mis lubab virtuaalservereid samal serveril ja/või samal IP-aadressil) ja lõpuks teine, mis sisaldab salvestatavaid andmeid, eraldatuna üksteisest & märgiga ja eelmistest ridadest ühega. tühi.

Ülaltoodud näites sisaldaks server nimega polaridad.es lehekülge failis /iot/grabar_temperatura, et hallata teavet, kasutades selle versiooni 1.1. HTTP protokoll

On näha, et kasutatakse kahte & märki, mis näitab, et kolm välja on salvestatud. Väljade nimed on võrdusmärgist vasakul ja nende määratlemiseks on kasutatud ainult kahte tähte. Päringu väljade (või soovi korral muutujate) nimena HTTP Need ei ole andmebaasis leiduvatega seotud, kirjeldavate tekstide kasutamine pole eriti oluline ning serveriga suhtluses teksti salvestamiseks ja andmeedastusprotsessi kiirendamiseks valitakse tavaliselt lühinimed (paarisnumbritega väljad).

Andmed, mida IoT-seade tavaliselt serverisse saadab, on numbrilist tüüpi, peamiselt täisarvud ja lihtsad kümnendkohad. Kui väärtused saadetakse tekstivormingus, nagu näites muutuja "ne" puhul, võivad tekkida ebasoodsad asjaolud, mida saab olenevalt juhtumist suurema või vähema edu ja kergusega lahendada. Sel juhul kasutatakse sõnade eraldamiseks plussmärke (+), mis asendavad tühikuid, mis muidu muudaksid POSTI taotlus. Üldine andmete saatmise viis, mis enamikul juhtudel lahendab, on märkide kuueteistkümnendkoodi näitamine, millele eelneb protsendimärk (%) Loogiliselt ei ole soovitatav seda ressurssi kasutada, välja arvatud juhul, kui kodeeritu on problemaatiline, kuna saadetavat suurendatakse, mis üldiselt nõuab rohkem ressursse, kuigi see on kindlasti väga väike.

Kuigi on võimalik opereerida a veebiserver Asjade Interneti jaoks ainult eelmise näite teabega lisavad paljud serverid, eriti avalikud, POST-päringule muid andmeid (kahjuks mitte alati ainult protokolliga) Allolev näide vastab kaevu taotletud postitamispäringule. - tuntud server. asjade Interneti avalik Asjad SPEAK.

Lisaks mõned isikuandmed, nagu X-THINGSPEAKAPIKEY (ja mis vastab iga kliendi identifikaatorile) eelmises näites on näha, et on ka teisi päiseid, mis lisavad päringule rohkem infot.

Kuidas kasutada päist a POSTI taotlus See koosneb lihtsalt selle nime, koolonmärgi (:), tühiku ja väärtuse kirjutamisest, mida soovite sellele määrata.

POST-päringute testimiseks veebiserverisse enne teiste komponentide seadistamise lõpetamist saab serveriga ühenduse luua ja andmed käsitsi saata. Näiteks Linuxi arvutis piisaks kasutamisest telnet polaridad.es 80 kus polaridad.es on serveri nimi ja 80 on pordi number, millele teenus vastab. HTTP.

Platvormidevahelist tööriista saab kasutada Linuxis, Windowsis või OS-is PuTTY, millest artiklis räägiti juhtida UART jadaseadmeid arvutist, et luua ühendus ilma konsooli kasutamata.

Järgnevatel HTTP päiste loend Seal on enamik neist, mis võivad olla kasulikud a POSTI taotlus kuni a veebiserver asjade Interneti jaoks.

• Accept Seda kasutatakse tüübi märkimiseks MIME mida taotlus eeldab, et server kasutab vastuses. Seda väljendatakse kui tipo/subtipo mida saab üldistada kasutades tärni (*) metamärgina, näiteks kui */* viidata mis tahes või tipo/* viidata kõikidele alatüüpidele tipo

  Kõige sagedamini kasutatavad on:

  • text/plain Kuigi see on kõige elementaarsem, on see ka enim kasutatud. See eeldab, et server tagastab lihtsa (lihtteksti) vastuse, millest piisab tehingu õigsusest teatamiseks ja maksimaalselt lisateabe lisamiseks, nagu salvestatud andmete tellimuse number, võrdluse tulemus, tehingu kuupäev. server…

  • application/xml o text/xml Oodake, kuni server vastab päringule vormingus XML. Valimise tähendus text asemel application võimaldab lihtsamat "inimlikku" lugemist (võrreldes "automaatse" lugemisega). See duaalsus avaldub ka teistes MIME tüübid kuid standardi tulevikutrend on eelistada application vastu text Vorming XML võimaldab palju andmeid sisaldavat vastust väga kindlal viisil struktureerida, puuduseks on see, et see lisab võrguandmetele palju kunstlikkust, mistõttu vastus võtab rohkem kui vaja, mistõttu on vaja rohkem ribalaiust ja tõenäoliselt rohkem IoT-seadme mälu, et seda töödelda.

  • text/html Kasutatakse siis, kui serveri vastus on HTML kodeeritud lihttekstina (lihttekstina), mis tavaliselt vormistab vastuse. Kuna tegemist on andmete salvestamisega ja vastus jõuaks väikesesse seadmesse ilma paljude ressurssideta, siis ei ole seda tüüpi tavaline kasutada.

  • application/xhtml+xml Põhimõtteliselt on see versioon XHTML (HTML kui XML kehtiv) eelmises jaotises oleva teabe kohta.

  • application/json Seda kasutatakse enim siis, kui serveri vastus sisaldab mitut teavet, sealhulgas rohkem või vähem keerukat struktuuri. Formaat JSON jaga vorminguga XML soliidne struktuur ja lisab eelise, et see on struktuuriga lisatud tekstis kokkuvõtlikum.

• Accept-Charset Määrab teksti kodeeringu, mida vastuses kasutatakse. Ladina tähtede kodeerimiseks UTF-8, kõige täiuslikum, ISO-8859 15, mis sisaldab euromärki (€) ja ISO-8859 1, mis on kõige elementaarsem.

• Accept-Encoding Näitab vormingut, mille järgi saab serveri vastust kodeerida. Põhimõtteliselt näitab see tihendamise tüüpi. Mõned kõige sagedasemad on gzip deflate (mida saab täpsemalt täpsustada deflate-raw o deflate-http) Seda ei kasutata asjade Internetiga ühendatud väikestes seadmetes, kuna see nõuab teatud ressursside tarbimist (mälu ja töötlemisaeg), mida seda tüüpi seadmetes tavaliselt napib. Pole vaja näidata, et kompressiooni ei kasutata Accept-Encoding: identity kuna vaikimisi arvestatakse sellist asjaolu.

• Accept-Language Väljendab keelt, mida saab vastuses kasutada. Näiteks Hispaania hispaania keel määratakse järgmiselt es-ES või Ameerika Ühendriikide inglise keel kui en-US

• Connection Seda kasutatakse selleks, et määrata, mida teha ühendusega, mis on loodud kliendi (IoT-seadme) ja veebiserver kui andmed on kätte saadud. Tavaliselt kasutatakse koos väärtusega close vormingus Connection: close näitamaks, et pärast kliendile vastamist tuleks ühendus sulgeda.

• Content-Length See võimaldab teil näidata baitide arvu, mille hõivab andmeid sisaldav päringu osa, mis asub pärast päiseid ja on eraldatud tühja reaga. See on väga kasulik, kuna see aitab kontrollida saadetud teabe terviklikkust; Kui see ei mõõda deklareeritut, siis seda ei salvestata, kuna leitakse, et see pole õigesti kohale jõudnud. Tavaliselt nõuavad seda enamik avalikke IoT-servereid.

• Content-Type Selle eesmärk on näidata MIME tüüp millega serverisse saadetav teave on kodeeritud. Tavaliselt kasutatakse tüüpe text/html kui serverisse saadetud andmed on väljendatud lihtsa väärtuste loendina (midagi taolist a=3.6&b=4.8) Ja application/jsonrequest (mis oleks samaväärne tüübiga application/json millest räägitakse aastal Accept), kui on vaja keerukamat struktuuri, kuid saata saab mis tahes järgmistest MIME tüüpide loend.

• Cookie Seda kasutatakse seansi identifikaatori lisamiseks, millega säilitada edastuste ahelat (päring, vastus, päring...), mis on keerulisem kui üksik päring, millega saata teatud seotud andmeid, mis on saadud erinevatel aegadel.

Sisukord


• Referer URL, mis pärineb POST-i päringust, näiteks veebileht, kust see saadeti. Kui seda kasutatakse asjade Interneti jaoks, ei lisa see asjakohast teavet, kuna teave saadetakse otse, ilma eelneva leheta, mistõttu seda sageli ei kasutata.

• User-Agent Teatab päringu esitanud seadmest. Tavalises veebiliikluses võimaldab asjade Internetis kasutatav brauser serveril näidata päringu esitava elektroonilise seadme tüübi. Enda tuvastamine serveris võimaldab vastust igal juhul erinevalt vormindada, näiteks tagastada brauserisse keeruline veebileht ja väikesele IoT-seadmele mõned hoiatusandmed.

Päistes on võimalik ühe väärtuse asemel määrata komadega eraldatud valikute loend, mis näitab, et korraga toetatakse mitut erinevat väärtust. Nendel väärtustel võib olla prioriteetsuse järjekord, mis on väljendatud vastavalt kvaliteedikoefitsiendile q. Kvaliteedikoefitsiendid eraldatakse semikooloniga (;) ja mis tahes tüübi või alamtüübi viitamiseks võib kasutada ka tärni (*).

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

Eelmises näites vormingu prioriteet JSON suurim (0.9) on lihtteksti ja vormindatud teksti oma. XML, mis vastavad spetsifikatsioonile text/*, on väiksem (0.8) ja nende vahel võrdne. Võimaluse korral peaks server reageerima vastuse kodeerimisega kui JSON.

Järgmises täielikuma POST-päringu näites pääseb serveri polaridad.es lehele /iot/grabar_temperatura juurde HTTP-protokolli versiooni 1.1 abil. Klient, nimega Sensoreitor-2000, saadab kodeeritud andmed sisse JSON, ootame vastust vormingus lihttekstina UTF-8 kasutades hispaania keelt Hispaaniast ilma pakkimiseta, mida muide pole vaja näidata. Serverisse saadetavad andmed võtavad enda alla 65 baiti. Vastuse saatmisel suletakse ühendus kliendi ja serveri vahel.

Järgmine artikkel selgitab kuidas seadistada MySQL-i andmebaas IoT-objektide saadetud teabe salvestamiseks