Lagra data på en IoT-webbserver med hjälp av HTTP POST-förfrågningar

Som förklaras i den första artikeln i serien lagra data som erhållits av Internet of Things-enheter, även om data som sparas hamnar på en server MySQL o mariadb och språket används PHP för att manipulera dem vid in- och utmatning sker informationsflödet mellan den elektroniska utrustningen och databasen med hjälp av en webbserver med vem du kommunicerar enligt HTTP-protokoll.

I början av definitionen av HTTP-protokoll Det fanns användningar jämförbara med den som beskrivs men faktum är att det i slutändan inte har utnyttjats fullt ut av olika anledningar, dels säkerhet och dels för att framsteg aldrig gjordes med att definiera ett mer specifikt eller mer effektivt protokoll, så nuförtiden, särskilt på offentliga servrar är det vanligaste att man använder en anslutning HTTP vad gör a POST-förfrågan till servern för att lagra informationen eller en FÅ för att återställa det, normalt för att visa en webbsida som presenterar det och till och med där du kan interagera.

Den mest grundläggande texten som skickas till servern i en förfrågan HTTP POST innehåller en rad med typen av begäran (POST) sökvägen till webbsidan som kommer att lagra informationen och versionen av HTTP-protokoll; en annan rad med värdnamnet (som tillåter virtuella servrar på samma server och/eller på samma IP-adress) och slutligen en annan som innehåller data som är inspelad, separerade från varandra med &-tecknet och från föregående rader med en tom.

I exemplet ovan skulle en server som heter polaridad.es innehålla en sida i /iot/grabar_temperatura för att hantera informationen med version 1.1 av HTTP-protokoll

Det kan ses att två & tecken används som visar att tre fält är lagrade. Namnet på fälten står till vänster om likhetstecknet och endast två bokstäver har använts för att definiera dem. Som namnet på fälten (eller variabler, om du föredrar det) för begäran HTTP De är inte relaterade till de i databasen, det är inte särskilt viktigt att använda beskrivande texter och korta namn väljs vanligtvis (jämna numrerade fält) för att spara text i kommunikation med servern och påskynda datasändningsprocessen.

Datan som en IoT-enhet normalt skickar till servern är av numerisk typ, främst heltal och enkla decimaler. När värden skickas i textformat, som är fallet med variabeln "ne" i exemplet, kan ogynnsamma omständigheter uppstå som kan lösas, beroende på fallet, med mer eller mindre framgång och lätthet. Vid detta tillfälle används plustecken (+) för att separera ord och ersätta mellanslag som annars skulle ändra POST-förfrågan. Ett generiskt sätt att skicka data som löser de flesta fall är genom att ange tecknets hexadecimala kod, föregås av procenttecknet (%) Logiskt är det inte tillrådligt att använda denna resurs förutom när det som är kodat är problematiskt eftersom Längden på det som skickas ökar, vilket generellt kräver mer resurser, även om det förvisso är mycket litet.

Även om det är möjligt att använda en webbserver För Internet of Things endast med informationen från föregående exempel, många servrar, särskilt offentliga, lägger till annan data till POST-frågan (tyvärr inte alltid begränsad till protokollet). Exemplet nedan motsvarar postbegäran som begärs av brunnen -känd server, offentlig för internet of things ThingSpeak.

Förutom vissa personuppgifter, som t.ex X-THINGSPEAKAPIKEY (och som motsvarar identifieraren för varje klient) i föregående exempel kan du se att det finns andra rubriker som lägger till mer information till begäran.

Hur man använder en rubrik i en POST-förfrågan Det består helt enkelt av att skriva dess namn, ett kolontecken (:), ett blanksteg och värdet du vill tilldela det.

För att testa POST-förfrågningar till webbservern innan konfigurationen av de andra komponenterna slutförs, kan en anslutning till servern upprättas och data skickas manuellt. Till exempel, på en Linux-dator skulle det räcka att använda telnet polaridad.es 80 där polaridad.es är namnet på servern och 80 är portnumret som tjänsten svarar på. HTTP.

Det plattformsoberoende verktyget kan användas på Linux, Windows eller OS PuTTY, som det talades om i artikeln styra UART seriella enheter från datorn, för att göra anslutningen utan att använda konsolen.

I nästa Lista med HTTP-rubriker Det finns de flesta som kan vara användbara för en POST-förfrågan till a webbserver för Internet of things.

• Accept Den används för att ange typen MIMA som förfrågan förväntar sig att servern ska använda i svaret. Det uttrycks som tipo/subtipo som kan generaliseras med asterisken (*) som jokertecken, till exempel som */* att hänvisa till någon eller tipo/* att hänvisa till alla undertyper av tipo

  De vanligaste är:

  • text/plain Även om det är det mest grundläggande, är det också det mest använda. Den förväntar sig att servern returnerar ett enkelt (oformaterad) textsvar som är tillräckligt för att meddela att transaktionen har varit korrekt och på sin höjd lägga till tillbehörsinformation såsom ordernumret på den registrerade datan, resultatet av en jämförelse, datumet för server...

  • application/xml o text/xml Vänta tills servern svarar på begäran i format XML. Meningen med att välja text istället för application möjliggör enklare "mänsklig" (versus "automatisk") läsning. Denna dualitet kommer att visa sig i andra MIME-typer men den framtida trenden för standarden är att föredra application framför text Formatet XML gör att ett svar som innehåller mycket data kan struktureras på ett mycket solidt sätt, nackdelen är att det tillför mycket konstgjordhet till nätdatan, vilket gör att svaret tar upp mer än nödvändigt, vilket kräver mer bandbredd och förmodligen mer minne i IoT-enheten för att bearbeta den.

  • text/html Används när serversvaret är html kodad som vanlig text (oformaterad text) som vanligtvis formaterar ett svar. Eftersom det handlar om att lagra data och svaret skulle nå en liten enhet utan många resurser är det inte vanligt att använda denna typ.

  • application/xhtml+xml I grund och botten är det versionen XHTML (html som XML giltig) av informationen i föregående avsnitt.

  • application/json Det används mest när serversvaret innehåller flera data inklusive en mer eller mindre komplex struktur. Formatet JSON dela med format XML en solid struktur och lägger till fördelen av att vara mer koncis i texten som lagts till av strukturen.

• Accept-Charset Bestämmer den textkodning som begärs att användas i svaret. För att koda latinska tecken, UTF-8, den mest kompletta, ISO-8859 15, som inkluderar eurotecknet (€) och ISO-8859 1, vilket är det mest grundläggande.

• Accept-Encoding Indikerar formatet enligt vilket serversvaret kan kodas. I grund och botten tjänar det till att indikera en typ av komprimering. Några av de vanligaste är gzip deflate (vilket kan specificeras mer i detalj med deflate-raw o deflate-http) Det är inte vanligt att använda det i små enheter anslutna till Internet of Things eftersom det kräver en viss förbrukning av resurser (minne och bearbetningstid) som vanligtvis är knappa i denna typ av utrustning. Det är inte nödvändigt att ange att komprimering inte används med Accept-Encoding: identity eftersom en sådan omständighet anses som standard.

• Accept-Language Uttrycker det språk som kan användas i svaret. Till exempel skulle Spaniens spanska anges som es-ES eller engelskan i Amerikas förenta stater som en-US

• Connection Den används för att specificera vad som ska göras med anslutningen som har upprättats mellan klienten (IoT-enheten) och webbserver när data har tagits emot. Används vanligtvis med värdet close i formatet Connection: close för att indikera att anslutningen ska stängas efter att ha svarat klienten.

• Content-Length Det låter dig ange antalet byte som upptas av den del av begäran som innehåller data, som är den efter rubrikerna och separerade med en tom rad. Det är mycket användbart eftersom det tjänar till att verifiera integriteten hos informationen som skickas; Om den inte mäter det som har deklarerats lagras den inte eftersom man anser att den inte kommit fram korrekt. Det krävs vanligtvis av de flesta offentliga IoT-servrar.

• Content-Type Det tjänar till att indikera MIME-typ med vilken informationen som skickas till servern kodas. Typerna används vanligtvis text/html när data som skickas till servern uttrycks som en enkel lista med värden (något liknande a=3.6&b=4.8) Och application/jsonrequest (vilket skulle vara motsvarigheten till typen application/json som det talas om i Accept) när en mer komplex struktur är nödvändig, men något av följande kan skickas lista över MIME-typer.

• Cookie Den används för att lägga till en sessionsidentifierare med vilken man kan upprätthålla en kedja av överföringar (fråga, svar, fråga...) som är mer komplex än en enda begäran för att skicka viss relaterad data men som erhålls vid olika tidpunkter.

Innehållsförteckning


• Referer URL som kom från POST-begäran, till exempel webbsidan som den skickades från. I fallet att den används för IoT lägger den inte till relevant information eftersom informationen skickas direkt, utan en tidigare sida, så den används inte ofta.

• User-Agent Rapporterar enheten som gör begäran. I normal webbtrafik tillåter webbläsaren som används i Internet of Things servern att ange vilken typ av elektronisk enhet som gör begäran. Genom att identifiera sig för servern kan svaret formateras på olika sätt i varje enskilt fall, till exempel genom att returnera en komplex webbsida till en webbläsare och några varningsdata till en liten IoT-enhet.

Det är möjligt att ange en kommaseparerad lista med alternativ istället för ett enda värde i rubriker för att indikera att flera olika värden stöds samtidigt. Dessa värden kan ha en prioritetsordning som uttrycks enligt en kvalitetskoefficient q för var och en. Kvalitetskoefficienter separeras med semikolon (;) och asterisker (*) kan också användas för att referera till vilken typ eller undertyp som helst.

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

I föregående exempel formatets prioritet JSON den största (0.9) är den för vanlig text och den för formaterad text. XML, som uppfyller specifikationen text/*, är mindre (0.8) och lika mellan dem. Om möjligt bör servern reagera genom att koda svaret som JSON.

I följande exempel på en mer komplett POST-förfrågan, nås /iot/grabar_temperatura-sidan på servern som heter polaridad.es med version 1.1 av HTTP-protokollet. Klienten, kallad Sensoreitor-2000, skickar in den kodade datan JSON, förvänta dig svaret som vanlig text i format UTF-8 använda spanska från Spanien utan att använda komprimering, vilket förresten inte är nödvändigt att indikera. Data som skickas till servern tar upp 65 byte. När svaret skickas stängs anslutningen mellan klienten och servern.

Följande artikel förklarar hur man konfigurerar MySQL-databas för att lagra information som skickas av IoT-objekt