Съхранявайте данни на IoT уеб сървър, като използвате HTTP POST заявки

Както е обяснено в първата статия от поредицата съхранява данни, получени от устройства за Интернет на нещата, въпреки че данните, които се записват, завършват на сървър MySQL o MariaDB и се използва език PHP за да ги манипулирате на входа и изхода, потокът от информация между електронното оборудване и базата данни се осъществява с помощта на a servidor web с когото общувате според HTTP протокол.

В началото на определението за HTTP протокол Имаше употреби, сравними с описаната, но факт е, че в крайна сметка тя не беше напълно използвана поради различни причини, отчасти сигурност и отчасти защото никога не е постигнат напредък в дефинирането на по-специфичен или по-ефективен протокол, така че днес, особено в публичните сървъри най-често срещаното нещо е да се използва връзка HTTP какво прави a POST заявка към сървъра за съхраняване на информацията или a GET за да го възстановите, обикновено за показване на уеб страница, която го представя и дори на която можете да взаимодействате.

Най-основният текст, изпратен до сървъра в заявка HTTP ПУСНИ включва ред с типа заявка (ПУСНИ) пътя до уеб страницата, която ще съхранява информацията и версията на HTTP протокол; друг ред с името на хоста (който позволява виртуални сървъри на същия сървър и/или на същия IP адрес) и накрая друг, който съдържа данните, които са записани, разделени един от друг със знака & и от предишните редове с един празно.

В примера по-горе сървър, наречен polaridad.es, ще съдържа страница в /iot/grabar_temperatura за управление на информацията, използвайки версия 1.1 на HTTP протокол

Вижда се, че са използвани два знака &, което показва, че са съхранени три полета. Името на полетата е отляво на знака за равенство и са използвани само две букви за тяхното дефиниране. Като името на полетата (или променливите, ако предпочитате) на заявката HTTP Те не са свързани с тези в базата данни, не е особено важно да се използват описателни текстове и обикновено се избират кратки имена (четни номерирани полета), за да се запази текстът при комуникация със сървъра и да се ускори процеса на изпращане на данни.

Данните, които едно IoT устройство обикновено изпраща до сървъра, са от числов тип, главно цели числа и прости десетични знаци. Когато стойностите се изпращат в текстов формат, какъвто е случаят с променливата "ne" в примера, могат да възникнат неблагоприятни обстоятелства, които могат да бъдат решени, в зависимост от случая, с повече или по-малко успех и лекота. В този случай знаците плюс (+) се използват за разделяне на думи, замествайки интервали, които иначе биха променили POST заявка. Общ начин за изпращане на данни, който разрешава повечето случаи, е чрез посочване на шестнадесетичния код на знаците, предшестван от знака за процент (%) Логично, не е препоръчително да използвате този ресурс, освен когато това, което е кодирано, е проблематично, тъй като дължината на какво се изпраща се увеличава, което обикновено изисква повече ресурси, въпреки че със сигурност е много малък по размер.

Въпреки че е възможно да се оперира a servidor web За интернет на нещата само с информацията от предишния пример, много сървъри, особено публични, добавят други данни към POST заявката (за съжаление не винаги се ограничават до протокола). Примерът по-долу съответства на заявката за публикация, поискана от добре -известен сървър. публичен за интернет на нещата ThingSpeak.

В допълнение към някои лични данни, като напр X-THINGSPEAKAPIKEY (и което съответства на идентификатора на всеки клиент) в предишния пример можете да видите, че има други заглавки, които добавят повече информация към заявката.

Как да използвате заглавка в a POST заявка Той просто се състои от писане на името му, знак за двоеточие (:), празно място и стойността, която искате да му присвоите.

За да тествате POST заявки към уеб сървъра, преди да завършите конфигурацията на другите компоненти, може да се установи връзка със сървъра и данните да се изпратят ръчно. Например, на компютър с Linux би било достатъчно да се използва telnet polaridad.es 80 където polaridad.es е името на сървъра и 80 е номерът на порта, на който услугата отговаря. HTTP.

Инструментът за различни платформи може да се използва на Linux, Windows или OS PuTTY, за което стана дума в статията управлява UART серийни устройства от компютър, за да осъществите връзката без да използвате конзолата.

В следващия Списък с HTTP заглавки Има повечето от тези, които могат да бъдат полезни за a POST заявка към a servidor web за интернет на нещата.

• Accept Използва се за обозначаване на типа Мим които заявката очаква сървърът да използва в отговора. Изразява се като tipo/subtipo което може да се обобщи с помощта на звездичката (*) като заместващ знак, например като */* да се отнасят до всякакви или tipo/* да се отнася до всички подвидове на tipo

  Най-често използваните са:

  • text/plain Въпреки че е най-основният, той е и най-използваният. Той очаква сървърът да върне прост (обикновен) текстов отговор, който е достатъчен, за да уведоми, че транзакцията е била правилна и най-много да добави допълнителна информация, като поръчков номер на записаните данни, резултат от сравнение, дата на сървър…

  • application/xml o text/xml Изчакайте сървърът да отговори на заявката във формат XML. Значението на избора text вместо application позволява по-лесно „човешко“ (срещу „автоматично“) четене. Тази двойственост ще се прояви в другите MIME типове но бъдещата тенденция на стандарта е да се предпочита application облицовка text Форматът XML позволява отговор, който съдържа много данни, да бъде структуриран по много солиден начин, недостатъкът е, че добавя много изкуственост към нетните данни, което прави отговора да заема повече от необходимото, следователно изисква повече честотна лента и вероятно повече памет в IoT устройството, за да го обработи.

  • text/html Използва се, когато отговорът на сървъра е HTML кодиран като обикновен текст (обикновен текст), обикновено форматиращ отговор. Тъй като става дума за съхраняване на данни и отговорът би достигнал до малко устройство без много ресурси, не е обичайно да се използва този тип.

  • application/xhtml+xml По принцип това е версията XHTML (HTML като XML валиден) на информацията в предишния раздел.

  • application/json Най-често се използва, когато отговорът на сървъра съдържа няколко данни, включително повече или по-малко сложна структура. Форматът JSON споделяне с формат XML солидна структура и добавя предимството да бъде по-сбит в текста, добавен от структурата.

• Accept-Charset Определя кодирането на текста, което се иска да се използва в отговора. За кодиране на латински символи, UTF-8, най-пълният, ISO-8859 15, което включва знака за евро (€) и ISO-8859 1, което е най-основното.

• Accept-Encoding Показва формата, според който отговорът на сървъра може да бъде кодиран. По принцип служи за указване на вид компресия. Някои от най-честите са gzip deflate (които могат да бъдат уточнени по-подробно с deflate-raw o deflate-http) Не е обичайно да се използва в малки устройства, свързани с Интернет на нещата, тъй като изисква определена консумация на ресурси (памет и време за обработка), които обикновено са оскъдни в тези видове оборудване. Не е необходимо да се посочва, че компресията не се използва с Accept-Encoding: identity тъй като такова обстоятелство се счита по подразбиране.

• Accept-Language Изразява езика, който може да се използва в отговора. Например испанският на Испания ще бъде посочен като es-ES или английският на Съединените американски щати като en-US

• Connection Използва се за указване какво трябва да се направи с връзката, която е установена между клиента (IoT устройството) и servidor web след като данните бъдат получени. Обикновено се използва със стойността close във формата Connection: close за да посочи, че връзката трябва да бъде затворена след отговор на клиента.

• Content-Length Тя ви позволява да посочите броя байтове, заети от частта от заявката, която съдържа данните, която е тази след заглавките и разделена с празен ред. Той е много полезен, тъй като служи за проверка на целостта на изпратената информация; Ако не измерва декларираното, не се съхранява, тъй като се счита, че не е пристигнало правилно. Обикновено се изисква от повечето публични IoT сървъри.

• Content-Type Служи за обозначаване на MIME тип с който се кодира информацията, изпратена до сървъра. Обикновено се използват видовете text/html когато данните, изпратени до сървъра, се изразяват като прост списък от стойности (нещо като a=3.6&b=4.8) Y application/jsonrequest (което би било еквивалентно на типа application/json за което се говори в Accept), когато е необходима по-сложна структура, но може да се изпрати всяко от следните списък с типове MIME.

• Cookie Използва се за добавяне на идентификатор на сесия, с който да се поддържа верига от трансфери (заявка, отговор, заявка...), която е по-сложна от една заявка, с която да се изпращат определени свързани данни, но получени по различно време.

Съдържание


• Referer URL адресът, който е инициирал POST заявката, например уеб страницата, от която е изпратена. В случай че се използва за IoT, той не добавя подходяща информация, тъй като информацията се изпраща директно, без предишна страница, така че не се използва често.

• User-Agent Докладва устройството, което прави заявката. При нормален уеб трафик браузърът, използван в Интернет на нещата, позволява на сървъра да посочи вида на електронното устройство, което прави заявката. Идентифицирането на сървъра позволява отговорът да бъде форматиран по различен начин във всеки случай, например връщане на сложна уеб страница към браузър и няколко предупредителни данни към малко IoT устройство.

Възможно е да посочите списък с опции, разделени със запетая, вместо една стойност в заглавките, за да посочите, че няколко различни стойности се поддържат едновременно. Тези стойности могат да имат ред на приоритет, който се изразява според коефициент на качество q за всяка от тях. Коефициентите на качество са разделени с точка и запетая (;) и звездичките (*) също могат да се използват за обозначаване на всеки тип или подтип.

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

В предишния пример приоритетът на формата JSON най-големият (0.9) е този на обикновен текст и този на форматиран текст. XML, които отговарят на спецификацията text/*, е по-малък (0.8) и равен между тях. Ако е възможно, сървърът трябва да реагира, като кодира отговора като JSON.

В следващия пример на по-пълна POST заявка, страницата /iot/grabar_temperatura на сървъра, наречена polaridad.es, е достъпна с помощта на версия 1.1 на HTTP протокола. Клиентът, наречен Sensoreitor-2000, изпраща кодираните данни JSON, очаквайте отговора като обикновен текст във формат UTF-8 използване на испански от Испания без използване на компресия, което между другото не е необходимо да се посочва. Данните, изпратени до сървъра, заемат 65 байта. При изпращане на отговора връзката между клиента и сървъра ще бъде затворена.

Следващата статия обяснява как да конфигурирате MySQL база данни за съхраняване на информация, изпратена от IoT обекти