Зберігайте дані на веб-сервері IoT за допомогою запитів HTTP POST

Як пояснюється в першій статті серії зберігати дані, отримані пристроями Інтернету речей, хоча збережені дані потрапляють на сервер MySQL o MariaDB і використовується мова PHP щоб маніпулювати ними на вході та виході, потік інформації між електронним обладнанням і базою даних відбувається за допомогою a веб-сервер з ким ви спілкуєтеся відповідно до протокол HTTP.

На початку визначення о протокол HTTP Існували випадки використання, подібні до описаного, але факт полягає в тому, що врешті-решт він не був повністю використаний з різних причин, частково безпеки, а частково через те, що ніколи не було досягнуто прогресу у визначенні більш конкретного чи ефективнішого протоколу, тому сьогодні, особливо на публічних серверах найпоширенішим є використання з’єднання HTTP що робить a POST запит на сервер для зберігання інформації або a GET щоб відновити його, як правило, щоб відобразити веб-сторінку, яка представляє його та навіть на якій ви можете взаємодіяти.

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

У наведеному вище прикладі сервер під назвою polaridad.es містив би сторінку в /iot/grabar_temperatura для керування інформацією за допомогою версії 1.1 протокол HTTP

Можна побачити, що використовуються два знаки &, що показує, що збережено три поля. Назви полів розташовано ліворуч від знака рівності, і для їх позначення використано лише дві літери. Як ім’я полів (або змінних, за бажанням) запиту HTTP Вони не пов’язані з тими, що містяться в базі даних, не особливо важливо використовувати описові тексти, і зазвичай вибираються короткі імена (парно пронумеровані поля), щоб зберегти текст у зв’язку з сервером і прискорити процес надсилання даних.

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

Хоча оперувати a веб-сервер Для Інтернету речей лише з інформацією з попереднього прикладу багато серверів, особливо загальнодоступних, додають інші дані до запиту POST (на жаль, не завжди обмежуються протоколом). Приклад нижче відповідає запиту на публікацію, який запитує добре -відомий сервер, загальнодоступний для Інтернету речей ThingSpeak.

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

Як використовувати заголовок у a POST запит Він просто складається з написання його назви, знака двокрапки (:), пробілу та значення, яке ви хочете йому призначити.

Щоб перевірити запити POST до веб-сервера перед завершенням налаштування інших компонентів, можна встановити з’єднання з сервером і надіслати дані вручну. Наприклад, на комп’ютері з ОС Linux достатньо було б використовувати telnet polaridad.es 80 де polaridad.es — ім’я сервера, а 80 — номер порту, на який відповідає служба. HTTP.

Кросплатформний інструмент можна використовувати в Linux, Windows або ОС PuTTY, про що йшлося в статті керувати послідовними пристроями UART з комп'ютера, щоб встановити з’єднання без використання консолі.

У наступному Список заголовків HTTP Є більшість тих, які можуть бути корисними для a POST запит має a веб-сервер для Інтернету речей.

• 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, наприклад веб-сторінка, з якої його було надіслано. У разі використання для 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 здійснюється за допомогою протоколу HTTP версії 1.1. Клієнт під назвою Sensoreitor-2000 надсилає закодовані дані JSON, очікуйте відповіді як звичайний текст у форматі UTF-8 використовуючи іспанську з Іспанії без використання стиснення, яке, до речі, вказувати не потрібно. Дані, що надсилаються на сервер, займають 65 байт. При надсиланні відповіді з'єднання між клієнтом і сервером буде закрито.

У наступній статті пояснюється як налаштувати базу даних MySQL для зберігання інформації, надісланої об’єктами IoT