Adatok tárolása egy IoT webszerveren HTTP POST kérések használatával

Ahogy a sorozat első cikkében kifejtjük tárolja az Internet of Things eszközök által szerzett adatokat, bár a mentett adatok egy szerverre kerülnek MySQL o MariaDB és nyelvet használnak PHP a bemeneten és a kimeneten történő manipuláláshoz az elektronikus berendezés és az adatbázis közötti információáramlás a segítségével történik szerver web akivel a szerint kommunikálsz HTTP protokoll.

A definíció elején HTTP protokoll Voltak a leírthoz hasonló felhasználási módok, de a tény az, hogy végül különböző okokból, részben biztonsági okokból, részben azért, mert soha nem történt előrelépés egy konkrétabb vagy hatékonyabb protokoll meghatározásában, végül nem sikerült teljesen kihasználni, így manapság különösen nyilvános szervereken a legelterjedtebb a kapcsolat használata HTTP mitől a POST kérés a szerverre az információ tárolására vagy a GET visszaállításához, általában egy olyan weboldal megjelenítéséhez, amely bemutatja, és amelyen interakciót is végezhet.

A kérésben a szervernek küldött legalapvetőbb szöveg HTTP POST tartalmaz egy sort a kérés típusával (POST) annak a weboldalnak az elérési útja, amely az információkat tárolja és a verzió verzióját HTTP protokoll; egy másik sor a gazdagép nevével (amely lehetővé teszi a virtuális szerverek használatát ugyanazon a szerveren és/vagy ugyanazon az IP-címen), és végül egy másik, amely a rögzített adatokat tartalmazza, egymástól & jellel, az előző soroktól eggyel elválasztva. üres.

A fenti példában a polaridad.es nevű kiszolgáló tartalmaz egy oldalt a /iot/grabar_temperatura fájlban, hogy kezelje az információkat a program 1.1-es verziójával. HTTP protokoll

Látható, hogy két & jelet használnak, ami azt mutatja, hogy három mező van tárolva. A mezők neve az egyenlőségjeltől balra található, és csak két betűt használtak a meghatározásához. A kérés mezőinek (vagy változóinak, ha úgy tetszik) neve HTTP Nem kapcsolódnak az adatbázisban szereplőkhöz, nem különösebben fontos a leíró szövegek használata, és általában rövid neveket választanak (páros számozott mezők), hogy a szerverrel kommunikáció során elmentsék a szöveget és felgyorsítsák az adatküldési folyamatot.

Az IoT-eszközök által a szervernek általában numerikus adatok, főleg egész számok és egyszerű tizedesjegyek. Amikor az értékeket szöveges formátumban küldjük el, mint a példa "ne" változója esetében, kedvezőtlen körülmények adódhatnak, amelyek esettől függően több-kevesebb sikerrel és könnyedén megoldhatók. Ebben az esetben pluszjeleket (+) használnak a szavak elválasztására, helyettesítve azokat a szóközöket, amelyek egyébként megváltoztatnák a szavakat POST kérés. Az adatok küldésének általános módja, amely a legtöbb esetet megoldja, a karakterek hexadecimális kódjának feltüntetése, amelyet a százalékjel (%) előz meg. Logikailag nem tanácsos ezt az erőforrást használni, kivéve, ha a kódolás problémás, mivel a az elküldött mennyiség megnövekszik, ami általában több erőforrást igényel, bár méretét tekintve természetesen nagyon kicsi.

Bár lehet működtetni a szerver web Az Internet of Things esetében csak az előző példa információival, sok szerver, különösen a nyilvánosak, más adatokat ad hozzá a POST lekérdezéshez (sajnos nem mindig csak a protokollra korlátozódik) Az alábbi példa megfelel a kút által kért bejegyzési kérésnek. - Ismert szerver. Nyilvános a dolgok internetéhez ThingSpeak.

Néhány személyes adat mellett, mint pl X-THINGSPEAKAPIKEY (és amely megfelel az egyes kliensek azonosítójának) az előző példában láthatja, hogy vannak más fejlécek, amelyek további információkat adnak a kéréshez.

A fejléc használata a POST kérés Egyszerűen a nevének beírásából, egy kettőspont jelből (:), egy üres szóközből és a hozzárendelni kívánt értékből áll.

A webszervernek küldött POST kérések teszteléséhez a többi komponens konfigurálásának befejezése előtt létre lehet hozni egy kapcsolatot a szerverrel, és manuálisan el lehet küldeni az adatokat. Például Linuxos számítógépen elég lenne használni telnet polaridad.es 80 ahol a polaridad.es a kiszolgáló neve, a 80 pedig a portszám, amelyen a szolgáltatás válaszol. HTTP.

A többplatformos eszköz Linuxon, Windowson vagy OS-en használható PuTTY, amiről a cikkben volt szó vezérelheti az UART soros eszközöket a számítógépről, a kapcsolat létrehozásához a konzol használata nélkül.

A következőben HTTP-fejlécek listája A legtöbb olyan van, amely hasznos lehet a POST kérés a szerver web a dolgok internetéhez.

• Accept A típus jelzésére szolgál PANTOMIM hogy a kérés elvárja, hogy a kiszolgáló használja a válaszban. Úgy van kifejezve tipo/subtipo amely általánosítható a csillag (*) használatával helyettesítő karakterként, például mint */* utalni bármely vagy tipo/* minden altípusra hivatkozni tipo

  A leggyakrabban használtak a következők:

  • text/plain Bár ez a legalapvetőbb, egyben a leggyakrabban használt. Azt várja el a szervertől, hogy egy egyszerű (sima) szöveges választ adjon vissza, amely elegendő annak jelzésére, hogy a tranzakció helyes volt, és legfeljebb olyan kiegészítő információkat ad hozzá, mint a rögzített adatok rendelési száma, az összehasonlítás eredménye, a tranzakció dátuma. szerver…

  • application/xml o text/xml Várja meg, amíg a szerver formátumban válaszol a kérésre XML. A választás értelme text helyett application könnyebb „emberi” (szemben az „automatikus”) olvasást teszi lehetővé. Ez a kettősség másokban is megjelenik MIME típusok de a szabvány jövőbeli trendje az, hogy előnyben részesítsék application előtt text A formátum XML lehetővé teszi a sok adatot tartalmazó válasz nagyon szilárd strukturálását, a hátránya az, hogy sok mesterkéltséget ad a netes adatokhoz, ami miatt a válasz a szükségesnél többet foglal, ezért nagyobb sávszélességet és valószínűleg több memória az IoT-eszközben a feldolgozásához.

  • text/html Akkor használatos, ha a szerver válasza HTML sima szövegként (plain text) kódolva, általában választ formázva. Mivel adattárolásról van szó, és a válasz sok erőforrás nélkül egy kis eszközhöz jutna el, nem elterjedt ennek a típusnak a használata.

  • application/xhtml+xml Alapvetően ez a verzió XHTML (HTML mint XML érvényes) az előző szakaszban található információk közül.

  • application/json Leggyakrabban akkor használatos, ha a kiszolgáló válasza több adatot tartalmaz, beleértve egy többé-kevésbé összetett struktúrát. A formátum JSON formátummal megosztani XML szilárd szerkezet, és azzal az előnnyel jár, hogy a szerkezet által hozzáadott szöveg tömörebb.

• Accept-Charset Meghatározza a válaszban használni kívánt szövegkódolást. A latin karakterek kódolásához a UTF-8, a legteljesebb, ISO-8859 15, amely tartalmazza az euró jelet (€) és a ISO-8859 1, ami a legalapvetőbb.

• Accept-Encoding Azt a formátumot jelzi, amely szerint a szerver válasza kódolható. Alapvetően a tömörítés típusának jelzésére szolgál. Néhány a leggyakoribb gzip deflate (amely részletesebben megadható deflate-raw o deflate-http) Nem elterjedt a Dolgok Internetére csatlakoztatott kis eszközökben való használata, mivel bizonyos erőforrás-felhasználást igényel (memória és feldolgozási idő), ami általában ritka az ilyen típusú berendezésekben. Nem szükséges jelezni, hogy a tömörítést nem használják Accept-Encoding: identity mivel alapesetben olyan körülményt vesznek figyelembe.

• Accept-Language A válaszban használható nyelvet fejezi ki. Például a spanyol spanyol a következőképpen lenne megadva es-ES vagy az Amerikai Egyesült Államok angolai mint en-US

• Connection Arra szolgál, hogy megadja, mit kell tenni a kliens (az IoT-eszköz) és a szerver web az adatok beérkezése után. Általában az értékkel együtt használják close formátumban Connection: close jelezni, hogy a kapcsolatot le kell zárni, miután válaszolt az ügyfélnek.

• Content-Length Lehetővé teszi, hogy jelezze, hogy a kérésnek az adatokat tartalmazó része hány bájtot foglal el, amely a fejlécek után található, és üres sorral van elválasztva. Nagyon hasznos, mivel a küldött információ sértetlenségének ellenőrzésére szolgál; Ha nem méri a bejelentettet, akkor nem tárolja, mivel úgy tekintik, hogy nem érkezett meg megfelelően. Általában a legtöbb nyilvános IoT-szervernek szüksége van rá.

• Content-Type Jelezésére szolgál a MIME típus amellyel a szerverre küldött információ kódolva van. Általában a típusokat használják text/html amikor a szervernek küldött adatok egyszerű értéklistaként vannak kifejezve (valami ilyesmi a=3.6&b=4.8) És application/jsonrequest (ami a típus megfelelője lenne application/json amiről van szó Accept), ha bonyolultabb szerkezetre van szükség, de a következők bármelyike ​​elküldhető MIME típusok listája.

• Cookie Egy munkamenet-azonosító hozzáadására szolgál, amellyel egy olyan átviteli láncot tarthat fenn (lekérdezés, válasz, lekérdezés...), amely összetettebb, mint egyetlen kérés, amellyel bizonyos kapcsolódó, de különböző időpontokban beszerzett adatok elküldhetők.

Tartalomjegyzék


• Referer URL, amelyből a POST kérés származott, például az a weboldal, amelyről küldték. IoT-re való felhasználás esetén nem ad hozzá releváns információkat, mivel az információkat közvetlenül, előző oldal nélkül küldik el, így nem használják gyakran.

• User-Agent Jelenti a kért eszközt. Normál webes forgalom esetén a dolgok internetében használt böngésző lehetővé teszi a szerver számára, hogy jelezze a kérést benyújtó elektronikus eszköz típusát. Az önazonosítás a kiszolgáló számára lehetővé teszi, hogy a választ minden esetben eltérően formázza, például egy összetett weboldal visszaküldése a böngészőnek és néhány figyelmeztető adat visszaküldése egy kis IoT-eszköznek.

Lehetőség van egy vesszővel elválasztott opciólista megadására a fejlécekben egyetlen érték helyett, jelezve, hogy egyszerre több különböző érték támogatott. Ezeknek az értékeknek lehet egy prioritási sorrendje, amelyet mindegyikre egy q minőségi együttható szerint fejeznek ki. A minőségi együtthatók pontosvesszővel (;) vannak elválasztva, és a csillagok (*) is használhatók bármely típusra vagy altípusra.

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

Az előző példában a formátum prioritása JSON a legnagyobb (0.9) az egyszerű szövegeké és a formázott szövegeké. XML, amelyek megfelelnek a specifikációnak text/*, kisebb (0.8) és egyenlő közöttük. Ha lehetséges, a kiszolgálónak a választ as kódolásával kell reagálnia JSON.

A teljesebb POST kérés alábbi példájában a polaridad.es nevű szerver /iot/grabar_temperatura oldala a HTTP protokoll 1.1-es verziójával érhető el. A Sensoreitor-2000 nevű kliens beküldi a kódolt adatokat JSON, a választ egyszerű szövegként várja UTF-8 spanyol nyelv használata Spanyolországból tömörítés nélkül, amit egyébként nem szükséges jelezni. A szerverre küldött adatok 65 bájtot foglalnak el. A válasz elküldésekor a kliens és a szerver közötti kapcsolat megszakad.

A következő cikk elmagyarázza hogyan konfigurálhatja a MySQL adatbázist az IoT-objektumok által küldött információk tárolására