Lagre data på en IoT-webserver ved å bruke HTTP POST-forespørsler

Som forklart i den første artikkelen i serien lagre data innhentet av Internet of Things-enheter, selv om dataene som lagres havner på en server MySQL o mariadb og språk brukes PHP for å manipulere dem ved inngang og utgang, skjer informasjonsflyten mellom det elektroniske utstyret og databasen ved hjelp av en servidor web som du kommuniserer med i henhold til HTTP-protokoll.

I begynnelsen av definisjonen av HTTP-protokoll Det var bruksområder som kan sammenlignes med den som beskrives, men faktum er at den til slutt ikke har blitt utnyttet fullt ut av ulike årsaker, dels sikkerhet og dels fordi det aldri ble gjort fremskritt med å definere en mer spesifikk eller mer effektiv protokoll, så i dag, spesielt i offentlige servere er det vanligste å bruke en tilkobling HTTP hva gjør en POST-forespørsel til serveren for å lagre informasjonen eller en GET for å gjenopprette den, vanligvis for å vise en nettside som presenterer den og til og med der du kan samhandle.

Den mest grunnleggende teksten sendt til serveren i en forespørsel HTTP POST inkluderer en linje med typen forespørsel (POST) banen til nettsiden som vil lagre informasjonen og versjonen av HTTP-protokoll; en annen linje med vertsnavnet (som tillater virtuelle servere på samme server og/eller på samme IP-adresse) og til slutt en annen som inneholder dataene som er registrert, atskilt fra hverandre med &-tegnet og fra de forrige linjene med én blank.

I eksemplet ovenfor vil en server kalt polaridad.es inneholde en side i /iot/grabar_temperatura for å administrere informasjonen ved å bruke versjon 1.1 av HTTP-protokoll

Det kan sees at det brukes to &-tegn som viser at tre felt er lagret. Navnet på feltene er til venstre for likhetstegnet og kun to bokstaver er brukt for å definere dem. Som navnet på feltene (eller variablene, hvis du foretrekker det) for forespørselen HTTP De er ikke relatert til de i databasen, det er ikke spesielt viktig å bruke beskrivende tekster og korte navn velges vanligvis (felt med jevne nummer) for å lagre tekst i kommunikasjon med serveren og fremskynde datasendingsprosessen.

Dataene som en IoT-enhet normalt sender til serveren er av numerisk type, hovedsakelig heltall og enkle desimaler. Når verdier sendes i tekstformat, slik tilfellet er med variabelen "ne" i eksemplet, kan det oppstå ugunstige omstendigheter som kan løses, avhengig av saken, med mer eller mindre suksess og letthet. Ved denne anledningen brukes plusstegn (+) for å skille ord, og erstatte mellomrom som ellers ville endre POST-forespørsel. En generisk måte å sende data på som løser de fleste tilfeller er ved å angi den heksadesimale koden til tegnene, foran med prosenttegnet (%) Logisk sett er det ikke tilrådelig å bruke denne ressursen bortsett fra når det som er kodet er problematisk siden Lengden på hva sendes økes, noe som generelt krever mer ressurser, selv om det absolutt er veldig lite i størrelse.

Selv om det er mulig å betjene en servidor web For tingenes internett kun med informasjonen fra forrige eksempel, legger mange servere, spesielt offentlige, til andre data til POST-spørringen (dessverre ikke alltid begrenset til protokollen). Eksemplet nedenfor tilsvarer postforespørselen som brønnen har bedt om. -kjent server, offentlig for tingenes internett ThingSpeak.

I tillegg til enkelte personopplysninger, som f.eks X-THINGSPEAKAPIKEY (og som tilsvarer identifikatoren til hver klient) i forrige eksempel kan du se at det er andre overskrifter som legger til mer informasjon til forespørselen.

Hvordan bruke en overskrift i en POST-forespørsel Den består ganske enkelt av å skrive navnet, et kolontegn (:), et tomt mellomrom og verdien du vil tilordne det.

For å teste POST-forespørsler til webserveren før konfigurasjonen av de andre komponentene fullføres, kan en tilkobling til serveren opprettes og dataene sendes manuelt. For eksempel, på en Linux-datamaskin ville det være nok å bruke telnet polaridad.es 80 der polaridad.es er navnet på serveren og 80 er portnummeret som tjenesten svarer på. HTTP.

Kryssplattformverktøyet kan brukes på Linux, Windows eller OS PuTTY, som ble omtalt i artikkelen kontrollere UART-serieenheter fra datamaskinen, for å opprette forbindelsen uten å bruke konsollen.

I det neste Liste over HTTP-overskrifter Det er de fleste som kan være nyttige for en POST-forespørsel til a servidor web for tingenes internett.

• Accept Den brukes til å angi typen MIME som forespørselen forventer at serveren skal bruke i svaret. Det uttrykkes som tipo/subtipo som kan generaliseres ved å bruke stjernen (*) som jokertegn, for eksempel som */* å referere til noen eller tipo/* å referere til alle undertyper av tipo

  De mest brukte er:

  • text/plain Selv om det er det mest grunnleggende, er det også det mest brukte. Den forventer at serveren returnerer et enkelt (ren) tekstsvar som er tilstrekkelig til å varsle om at transaksjonen har vært korrekt og på det meste legge til tilleggsinformasjon som ordrenummeret til de registrerte dataene, resultatet av en sammenligning, datoen for server …

  • application/xml o text/xml Vent til serveren svarer på forespørselen i format XML. Meningen med å velge text i stedet for application muliggjør enklere "menneskelig" (versus "automatisk") lesing. Denne dualiteten vil presentere seg i andre MIME-typer men den fremtidige trenden til standarden er å foretrekke application foran text Formatet XML lar en respons som inneholder mye data struktureres på en veldig solid måte, ulempen er at den legger mye kunstighet til nettdataene, noe som gjør at responsen tar opp mer enn nødvendig, og krever derfor mer båndbredde og sannsynligvis mer minne i IoT-enheten for å behandle den.

  • text/html Brukes når serverresponsen er HTML kodet som ren tekst (ren tekst) som vanligvis formaterer et svar. Siden det handler om å lagre data og responsen ville nå en liten enhet uten mange ressurser, er det ikke vanlig å bruke denne typen.

  • application/xhtml+xml I utgangspunktet er det versjonen XHTML (HTML som XML gyldig) av informasjonen i forrige avsnitt.

  • application/json Det er mest brukt når serversvaret inneholder flere data inkludert en mer eller mindre kompleks struktur. Formatet JSON dele med format XML en solid struktur og legger til fordelen av å være mer konsis i teksten lagt til av strukturen.

• Accept-Charset Bestemmer tekstkodingen som blir bedt om å brukes i svaret. For å kode latinske tegn, UTF-8, den mest komplette, ISO-8859 15, som inkluderer eurotegnet (€) og ISO-8859 1, som er det mest grunnleggende.

• Accept-Encoding Indikerer formatet som serverresponsen kan kodes i henhold til. I utgangspunktet tjener det til å indikere en type komprimering. Noen av de hyppigste er gzip deflate (som kan spesifiseres mer detaljert med deflate-raw o deflate-http) Det er ikke vanlig å bruke det i små enheter koblet til tingenes internett siden det krever et visst forbruk av ressurser (minne og behandlingstid) som vanligvis er knappe i denne typen utstyr. Det er ikke nødvendig å indikere at komprimering ikke brukes med Accept-Encoding: identity siden en slik omstendighet anses som standard.

• Accept-Language Uttrykker språket som kan brukes i besvarelsen. For eksempel vil spansken i Spania bli spesifisert som es-ES eller engelskmennene i Amerikas forente stater som en-US

• Connection Den brukes til å spesifisere hva som skal gjøres med forbindelsen som er opprettet mellom klienten (IoT-enheten) og servidor web når dataene er mottatt. Brukes vanligvis med verdien close i formatet Connection: close for å indikere at forbindelsen skal lukkes etter å ha svart klienten.

• Content-Length Den lar deg angi antall byte som er okkupert av den delen av forespørselen som inneholder dataene, som er den etter overskriftene og atskilt med en tom linje. Det er veldig nyttig siden det tjener til å verifisere integriteten til informasjonen som sendes; Hvis den ikke måler opp det som er deklarert, lagres den ikke siden det vurderes at den ikke har kommet riktig frem. Det kreves vanligvis av de fleste offentlige IoT-servere.

• Content-Type Det tjener til å indikere MIME-type som informasjonen som sendes til serveren er kodet med. Typene brukes vanligvis text/html når dataene som sendes til serveren uttrykkes som en enkel liste over verdier (noe sånt som a=3.6&b=4.8) Og application/jsonrequest (som vil tilsvare typen application/json som det er snakk om i Accept) når en mer kompleks struktur er nødvendig, men noe av det følgende kan sendes liste over MIME-typer.

• Cookie Den brukes til å legge til en sesjonsidentifikator for å vedlikeholde en kjede av overføringer (spørring, svar, spørring...) som er mer kompleks enn en enkelt forespørsel for å sende visse relaterte data, men innhentet på forskjellige tidspunkter.

Innholdsfortegnelse


• Referer URL som oppsto POST-forespørselen, for eksempel nettsiden den ble sendt fra. I tilfelle den brukes til IoT, legger den ikke til relevant informasjon siden informasjonen sendes direkte, uten en tidligere side, så den brukes ikke ofte.

• User-Agent Rapporterer enheten som sender forespørselen. I normal nettrafikk lar nettleseren som brukes i tingenes internett serveren indikere hvilken type elektronisk enhet som sender forespørselen. Ved å identifisere seg til serveren kan svaret formateres forskjellig i hvert enkelt tilfelle, for eksempel returnering av en kompleks nettside til en nettleser og noen få advarselsdata til en liten IoT-enhet.

Det er mulig å spesifisere en kommadelt liste over alternativer i stedet for en enkelt verdi i overskrifter for å indikere at flere forskjellige verdier støttes samtidig. Disse verdiene kan ha en prioritetsrekkefølge som er uttrykt i henhold til en kvalitetskoeffisient q for hver enkelt. Kvalitetskoeffisienter er atskilt med semikolon (;) og asterisker (*) kan også brukes for å referere til enhver type eller undertype.

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

I forrige eksempel prioriteres formatet JSON den største (0.9) er den for ren tekst og den for formatert tekst. XML, som oppfyller spesifikasjonen text/*, er mindre (0.8) og lik mellom dem. Om mulig bør serveren reagere ved å kode svaret som JSON.

I følgende eksempel på en mer fullstendig POST-forespørsel, åpnes /iot/grabar_temperatura-siden til serveren kalt polaridad.es ved å bruke versjon 1.1 av HTTP-protokollen. Klienten, kalt Sensoreitor-2000, sender de kodede dataene inn JSON, forvent svaret som ren tekst i format UTF-8 bruke spansk fra Spania uten å bruke komprimering, noe som forresten ikke er nødvendig å indikere. Dataene som sendes til serveren tar opp 65 byte. Når du sender svaret, vil forbindelsen mellom klienten og serveren bli stengt.

Følgende artikkel forklarer hvordan konfigurere MySQL-databasen til å lagre informasjon sendt av IoT-objekter