Храните данные на веб-сервере IoT с помощью HTTP-запросов POST.

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

В начале определения HTTP-протокол Были случаи использования, сравнимые с описанным, но факт в том, что в конце концов он не был полностью использован по разным причинам, частично из-за безопасности, а частично из-за того, что так и не был достигнут прогресс в определении более конкретного или более эффективного протокола, поэтому в настоящее время, особенно на публичных серверах чаще всего используется соединение HTTP что делает POST-запрос на сервер для хранения информации или ПОЛУЧИТЬ чтобы восстановить его, обычно для отображения веб-страницы, на которой он представлен и даже с которой вы можете взаимодействовать.

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

В приведенном выше примере сервер с именем Polaridad.es будет содержать страницу в /iot/grabar_temperatura для управления информацией с использованием версии 1.1 HTTP-протокол

Видно, что используются два знака &, которые показывают, что сохранены три поля. Название полей находится слева от знака равенства, и для их определения использованы всего две буквы. В качестве имени полей (или переменных, если хотите) запроса HTTP Они не связаны с теми, что находятся в базе данных, не особенно важно использовать описательные тексты и обычно выбираются короткие имена (четные нумерованные поля), чтобы сохранить текст при общении с сервером и ускорить процесс отправки данных.

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

Хотя можно эксплуатировать веб-сервер Для Интернета вещей только с информацией из предыдущего примера многие серверы, особенно публичные, добавляют в POST-запрос и другие данные (к сожалению, не всегда ограничиваются протоколом).Пример ниже соответствует почтовому запросу, запрошенному ну -известный сервер, общедоступный для Интернета вещей ВещьГоворить.

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

Как использовать заголовок в POST-запрос Он просто состоит из написания его имени, знака двоеточия (:), пробела и значения, которое вы хотите ему присвоить.

Чтобы протестировать POST-запросы к веб-серверу перед завершением настройки других компонентов, можно установить соединение с сервером и отправить данные вручную. Например, на компьютере Linux было бы достаточно использовать telnet polaridad.es 80 где Polaridad.es — имя сервера, а 80 — номер порта, на котором отвечает служба. HTTP.

Кроссплатформенный инструмент можно использовать в Linux, Windows или ОС. PuTTY, о котором говорилось в статье управлять последовательными устройствами UART с компьютера, чтобы установить соединение без использования консоли.

В следующем Список HTTP-заголовков Большинство из них могут быть полезны для POST-запрос к веб-сервер для Интернета вещей.

• Accept Используется для обозначения типа MIME который запрос ожидает от сервера в ответе. Это выражается как 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) и веб-сервер как только данные будут получены. Обычно используется со значением close в формате Connection: close чтобы указать, что соединение должно быть закрыто после ответа клиенту.

• Content-Length Он позволяет указать количество байтов, занимаемых частью запроса, содержащей данные, которая находится после заголовков и отделена пустой строкой. Это очень полезно, поскольку служит для проверки целостности отправляемой информации; Если он не измеряет заявленное, оно не сохраняется, поскольку считается, что оно прибыло неправильно. Обычно это требуется большинству общедоступных серверов IoT.

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

• Cookie Он используется для добавления идентификатора сеанса, с помощью которого поддерживается цепочка передач (запрос, ответ, запрос...), которая более сложна, чем одиночный запрос для отправки определенных связанных данных, но полученный в разное время.

Содержание


• Referer URL-адрес, отправивший запрос POST, например веб-страница, с которой он был отправлен. В случае использования для Интернета вещей соответствующая информация не добавляется, поскольку информация отправляется напрямую, без предыдущей страницы, поэтому она не используется часто.

• 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