Shranite podatke na spletni strežnik IoT z uporabo zahtev HTTP POST

Shranite podatke na spletni strežnik IoT z uporabo zahtev HTTP POST

Shranite podatke na spletni strežnik IoT z uporabo zahtev HTTP POST

IoT spletni strežnikHTTP POST IoT spletni strežnikBaza podatkov MySQL. IoT spletni strežnikJezik PHP IoT spletni strežnik

Kot je pojasnjeno v prvem članku serije shranjevanje podatkov, pridobljenih z napravami interneta stvari, čeprav shranjeni podatki končajo na strežniku MySQL o MariaDB in jezik se uporablja PHP za manipulacijo z njimi pri vhodu in izhodu poteka pretok informacij med elektronsko opremo in bazo podatkov z uporabo a spletni strežnik s katerimi komunicirate glede na protokol HTTP.

Na začetku definicije protokol HTTP Obstajale so uporabe, primerljive z opisano, a dejstvo je, da na koncu ni bila v celoti izkoriščena zaradi različnih razlogov, delno zaradi varnosti in delno zato, ker nikoli ni bil dosežen napredek pri definiranju natančnejšega ali učinkovitejšega protokola, tako da danes, zlasti v javnih strežnikih je najpogostejša uporaba povezave HTTP kaj naredi a POST zahteva strežniku za shranjevanje informacij ali a GET da ga obnovite, običajno za prikaz spletne strani, ki ga predstavlja in na kateri lahko celo komunicirate.

Najosnovnejše besedilo, poslano strežniku v zahtevi HTTP POST vključuje vrstico z vrsto zahteve (POST) pot do spletne strani, ki bo shranila podatke in različico protokol HTTP; druga vrstica z imenom gostitelja (ki omogoča virtualne strežnike na istem strežniku in/ali na istem naslovu IP) in končno druga, ki vsebuje podatke, ki so zabeleženi, ločeni med seboj z znakom & in od prejšnjih vrstic z enim prazno.

V zgornjem primeru bi strežnik z imenom polaridad.es vseboval stran v /iot/grabar_temperatura za upravljanje informacij z uporabo različice 1.1 protokol HTTP

Vidimo, da sta uporabljena dva znaka &, kar kaže, da so shranjena tri polja. Imena polj so levo od znaka enačaja in za njihovo opredelitev sta bili uporabljeni samo dve črki. Kot ime polj (ali spremenljivk, če želite) zahteve HTTP Niso povezani s tistimi v bazi podatkov, uporaba opisnih besedil ni posebej pomembna, običajno se izberejo kratka imena (sodo oštevilčena polja), da se besedilo shrani v komunikaciji s strežnikom in pospeši proces pošiljanja podatkov.

Podatki, ki jih naprava IoT običajno pošlje strežniku, so številske vrste, večinoma cela števila in preprosta decimalka. Ko so vrednosti poslane v besedilni obliki, kot je to primer s spremenljivko "ne" v primeru, lahko pride do neugodnih okoliščin, ki jih je mogoče rešiti, odvisno od primera, z več ali manj uspeha in lahkoto. Ob tej priložnosti se za ločevanje besed uporabljajo znaki plus (+), ki nadomeščajo presledke, ki bi sicer spremenili POST zahteva. Generičen način pošiljanja podatkov, ki reši večino primerov, je navedba šestnajstiške kode znakov, pred katero je znak za odstotek (%). Logično je, da uporaba tega vira ni priporočljiva, razen kadar je kodirano problematično, saj je dolžina je poslano povečano, kar na splošno zahteva več sredstev, čeprav je vsekakor zelo majhno.

Čeprav je možno operirati a spletni strežnik Za internet stvari samo z informacijami iz prejšnjega primera številni strežniki, zlasti javni, poizvedbi POST dodajo druge podatke (žal niso vedno omejeni na protokol). Spodnji primer ustreza zahtevi za objavo, ki jo zahteva dobro -znani strežnik, javni za internet stvari ThingSpeak.

Poleg nekaterih osebnih podatkov, kot je npr X-THINGSPEAKAPIKEY (in ki ustreza identifikatorju vsakega odjemalca) v prejšnjem primeru lahko vidite, da obstajajo še druge glave, ki zahtevi dodajo več informacij.

Kako uporabiti glavo v a POST zahteva Preprosto je sestavljen iz zapisa imena, dvopičja (:), praznega prostora in vrednosti, ki mu jo želite dodeliti.

Če želite preskusiti zahteve POST do spletnega strežnika, preden dokončate konfiguracijo drugih komponent, je mogoče vzpostaviti povezavo s strežnikom in podatke poslati ročno. Na primer, v računalniku z Linuxom bi bilo dovolj za uporabo telnet polaridad.es 80 kjer je polaridad.es ime strežnika in 80 številka vrat, na katerih se storitev odziva. HTTP.

Povežite se s spletnim strežnikom polaridad.es s pomočjo telneta za shranjevanje podatkov IoT

Orodje za več platform se lahko uporablja v sistemih Linux, Windows ali OS PuTTY, o čemer je bilo govora v članku nadzor serijskih naprav UART iz računalnika, da vzpostavite povezavo brez uporabe konzole.

Povežite se s spletnim strežnikom polaridad.es z uporabo PuTTY za shranjevanje podatkov IoT

V naslednjem Seznam glav HTTP Največ je takih, ki so lahko uporabni za a POST zahteva ima a spletni strežnik za internet stvari.

  • Accept Uporablja se za označevanje vrste Mime ki zahteva zahteva, da jo strežnik uporabi v odgovoru. Izraža se kot tipo/subtipo ki se lahko posploši z zvezdico (*) kot nadomestnim znakom, na primer kot */* sklicevati se na katero koli oz tipo/* nanašati na vse podtipe tipo

    Najpogosteje uporabljeni so:

    • text/plain Čeprav je najbolj osnovna, je tudi najpogosteje uporabljena. Pričakuje, da bo strežnik vrnil preprost odgovor (navadno) z besedilom, ki zadostuje za obvestilo, da je bila transakcija pravilna, in kvečjemu doda dodatne informacije, kot so številka naročila zabeleženih podatkov, rezultat primerjave, datum strežnik…

    • application/xml o text/xml Počakajte, da strežnik odgovori na zahtevo v formatu XML. Pomen izbire text namesto application omogoča lažje »človeško« (v primerjavi z »samodejnim«) branje. Ta dvojnost se bo pokazala v drugih vrste MIME vendar je prihodnji trend standarda prednost application pred text Oblika XML omogoča, da je odgovor, ki vsebuje veliko podatkov, strukturiran na zelo trden način, pomanjkljivost pa je, da neto podatkom doda veliko umetnosti, zaradi česar odgovor zavzame več, kot je potrebno, zato zahteva večjo pasovno širino in verjetno več pomnilnik v napravi IoT za obdelavo.

    • text/html Uporablja se, ko je odgovor strežnika HTML kodirano kot navadno besedilo (navadno besedilo), ki običajno oblikuje odgovor. Ker gre za shranjevanje podatkov in bi odziv dosegel majhno napravo brez veliko virov, uporaba te vrste ni običajna.

    • application/xhtml+xml V bistvu je različica XHTML (HTML kot XML veljavna) informacij iz prejšnjega razdelka.

    • application/json Najpogosteje se uporablja, ko odgovor strežnika vsebuje več podatkov, vključno z bolj ali manj kompleksno strukturo. Oblika JSON delite z obliko XML trdno strukturo in doda prednost, da je bolj jedrnat v besedilu, ki ga doda struktura.

  • Accept-Charset Določa kodiranje besedila, ki se zahteva za uporabo v odgovoru. Za kodiranje latiničnih znakov je UTF-8, najbolj popoln, ISO-8859 15, ki vključuje znak za evro (€) in ISO-8859 1, ki je najbolj osnovna.

  • Accept-Encoding Označuje obliko, v skladu s katero je mogoče kodirati odgovor strežnika. V bistvu služi za označevanje vrste stiskanja. Nekatere najpogostejše so gzip deflate (kar lahko podrobneje določite z deflate-raw o deflate-http) Ni običajno, da bi ga uporabljali v majhnih napravah, povezanih z internetom stvari, saj zahteva določeno porabo virov (pomnilnik in čas obdelave), ki jih je pri tovrstni opremi običajno malo. Ni treba navesti, da se stiskanje ne uporablja z Accept-Encoding: identity saj se taka okoliščina privzeto upošteva.

  • Accept-Language Izraža jezik, ki se lahko uporabi v odgovoru. Na primer, španščina Španije bi bila navedena kot es-ES ali angleščina Združenih držav Amerike kot en-US

  • Connection Uporablja se za določitev, kaj naj se naredi s povezavo, ki je bila vzpostavljena med odjemalcem (napravo IoT) in spletni strežnik ko so podatki prejeti. Običajno se uporablja z vrednostjo close v formatu Connection: close da pokaže, da je treba povezavo zapreti po odgovoru odjemalcu.

  • Content-Length Omogoča vam, da navedete število bajtov, ki jih zaseda del zahteve, ki vsebuje podatke, ki je tisti za glavami in ločen s prazno vrstico. Je zelo uporaben, saj služi za preverjanje celovitosti poslanih informacij; Če ne izmeri deklariranega, se ne shrani, saj se šteje, da ni pravilno prispelo. Običajno ga zahteva večina javnih strežnikov IoT.

  • Content-Type Služi za označevanje Vrsta MIME s katerim so kodirane informacije, poslane na strežnik. Običajno se uporabljajo vrste text/html ko so podatki, poslani strežniku, izraženi kot preprost seznam vrednosti (nekaj podobnega a=3.6&b=4.8) In application/jsonrequest (kar bi bilo enakovredno vrsti application/json o katerem se govori v Accept), ko je potrebna bolj zapletena struktura, lahko pa se pošlje kar koli od naslednjega seznam vrst MIME.

  • Cookie Uporablja se za dodajanje identifikatorja seje, s katerim vzdržujemo verigo prenosov (poizvedba, odgovor, poizvedba ...), ki je bolj zapletena kot ena zahteva, s katero pošiljamo določene povezane podatke, vendar pridobljene ob različnih časih.

  • Kazalo
    • Referer URL, ki je sprožil zahtevo POST, na primer spletna stran, s katere je bila poslana. V primeru uporabe za IoT ne doda ustreznih informacij, saj se informacije pošljejo neposredno, brez predhodne strani, zato se ne uporablja pogosto.

    • User-Agent Sporoči napravo, ki je poslala zahtevo. V običajnem spletnem prometu brskalnik, ki se uporablja v internetu stvari, strežniku omogoča, da navede vrsto elektronske naprave, ki pošilja zahtevo. Identifikacija strežniku omogoča, da se odgovor v vsakem primeru drugače oblikuje, na primer vrnitev zapletene spletne strani brskalniku in nekaj opozorilnih podatkov majhni napravi IoT.

    Namesto ene same vrednosti v glavah je mogoče določiti seznam možnosti, ločenih z vejicami, kar pomeni, da je podprtih več različnih vrednosti hkrati. Te vrednosti imajo lahko prednostni vrstni red, ki je izražen glede na koeficient kakovosti q za vsako od njih. Koeficienti kakovosti so ločeni s podpičjem (;), zvezdice (*) pa se lahko uporabljajo tudi za sklicevanje na katero koli vrsto ali podvrsto.

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

    V prejšnjem primeru prednost formata JSON največji (0.9) je golo besedilo in formatirano besedilo. XML, ki ustrezajo specifikaciji text/*, je manjši (0.8) in med njima enak. Če je mogoče, naj se strežnik odzove tako, da kodira odgovor kot JSON.

    V naslednjem primeru popolnejše zahteve POST se do strani /iot/grabar_temperatura strežnika, imenovane polaridad.es, dostopa z različico 1.1 protokola HTTP. Odjemalec, imenovan Sensoreitor-2000, pošlje kodirane podatke JSON, pričakujte odgovor kot golo besedilo v formatu UTF-8 z uporabo španščine iz Španije brez uporabe stiskanja, ki ga mimogrede ni treba navesti. Podatki, poslani na strežnik, zavzamejo 65 bajtov. Pri pošiljanju odgovora se povezava med odjemalcem in strežnikom prekine.

    Naslednji članek pojasnjuje kako konfigurirati bazo podatkov MySQL za shranjevanje informacij, ki jih pošiljajo predmeti IoT

    po Komentar

    Morda ste zamudili