Przechowuj dane na serwerze internetowym IoT przy użyciu żądań HTTP POST

Jak wyjaśniono w pierwszym artykule z serii przechowują dane pozyskane przez urządzenia Internetu Rzeczy, chociaż zapisane dane trafiają na serwer MySQL o MariaDB i używany jest język PHP aby manipulować nimi na wejściu i wyjściu, przepływ informacji pomiędzy sprzętem elektronicznym a bazą danych odbywa się za pomocą a serwer internetowy z kim komunikujesz się zgodnie z Protokół HTTP.

Na początek definicja Protokół HTTP Były zastosowania porównywalne do opisanego, ale faktem jest, że ostatecznie nie zostały one w pełni wykorzystane z różnych powodów, częściowo ze względu na bezpieczeństwo, a częściowo dlatego, że nigdy nie poczyniono postępu w definiowaniu bardziej szczegółowego i wydajnego protokołu, więc obecnie, szczególnie na serwerach publicznych najczęstszą rzeczą jest użycie połączenia HTTP co sprawia, że ​​A Żądanie POST do serwera w celu przechowywania informacji lub a GET aby go odzyskać, zwykle w celu wyświetlenia strony internetowej, która go prezentuje, a nawet na której można wchodzić w interakcję.

Najbardziej podstawowy tekst wysyłany do serwera w żądaniu HTTP POST zawiera linię z typem żądania (POST) ścieżka do strony internetowej, na której będą przechowywane informacje oraz wersja pliku Protokół HTTP; kolejna linia z nazwą hosta (co pozwala na wirtualne serwery na tym samym serwerze i/lub pod tym samym adresem IP) i wreszcie kolejna, która zawiera rejestrowane dane, oddzielone od siebie znakiem & i od poprzednich linijek jedną pusty.

W powyższym przykładzie serwer o nazwie polaridad.es będzie zawierał stronę w /iot/grabar_temperatura do zarządzania informacjami przy użyciu wersji 1.1 Protokół HTTP

Można zauważyć, że używane są dwa znaki &, które wskazują, że przechowywane są trzy pola. Nazwy pól znajdują się po lewej stronie znaku równości i do ich zdefiniowania użyto tylko dwóch liter. Jako nazwa pól (lub zmiennych, jeśli wolisz) żądania HTTP Nie są one powiązane z tymi w bazie danych, nie jest szczególnie istotne stosowanie tekstów opisowych i zazwyczaj wybierane są krótkie nazwy (pola parzyste numerowane), aby zapisać tekst w komunikacji z serwerem i przyspieszyć proces przesyłania danych.

Dane, które urządzenie IoT zwykle wysyła do serwera, są typu numerycznego i obejmują głównie liczby całkowite i proste miejsca po przecinku. Gdy wartości przesyłane są w formacie tekstowym, jak ma to miejsce w przypadku zmiennej „ne” w przykładzie, mogą wystąpić niesprzyjające okoliczności, które w zależności od przypadku można rozwiązać z mniejszym lub większym sukcesem i łatwością. Przy tej okazji znaki plus (+) są używane do oddzielania słów, zastępując spacje, które w przeciwnym razie zmieniałyby Żądanie POST. Ogólny sposób wysyłania danych, który rozwiązuje większość przypadków, polega na wskazaniu kodu szesnastkowego znaków, poprzedzonego znakiem procentu (%). Logicznie rzecz biorąc, nie zaleca się używania tego zasobu, z wyjątkiem sytuacji, gdy zakodowane treści stwarzają problemy, ponieważ Długość tego, co wysyłany jest zwiększony, co generalnie wymaga więcej zasobów, chociaż z pewnością jest bardzo mały.

Chociaż możliwa jest obsługa a serwer internetowy W przypadku Internetu Rzeczy tylko na podstawie informacji z poprzedniego przykładu wiele serwerów, zwłaszcza publicznych, dodaje do zapytania POST inne dane (niestety nie zawsze ograniczone do protokołu). Poniższy przykład odpowiada żądaniu postu żądanemu przez studnię -znany serwer publiczny dla Internetu rzeczy RzeczMów.

Oprócz niektórych danych osobowych, takich jak X-THINGSPEAKAPIKEY (i który odpowiada identyfikatorowi każdego klienta) w poprzednim przykładzie widać, że istnieją inne nagłówki, które dodają więcej informacji do żądania.

Jak używać nagłówka w pliku Żądanie POST Składa się po prostu z wpisania jego nazwy, znaku dwukropka (:), spacji i wartości, którą chcesz mu przypisać.

Aby przetestować żądania POST kierowane do serwera WWW przed zakończeniem konfiguracji pozostałych komponentów, można nawiązać połączenie z serwerem i ręcznie przesłać dane. Na przykład na komputerze z systemem Linux wystarczyłoby użyć telnet polaridad.es 80 gdzie polaridad.es to nazwa serwera, a 80 to numer portu, na którym odpowiada usługa. HTTP.

Z tego wieloplatformowego narzędzia można korzystać w systemach Linux, Windows i OS PuTTY, o czym była mowa w artykule sterować urządzeniami szeregowymi UART z komputera, aby nawiązać połączenie bez korzystania z konsoli.

W następnym Lista nagłówków HTTP Jest większość z nich, które mogą być przydatne dla Żądanie POST do serwer internetowy dla Internetu rzeczy.

• Accept Służy do wskazania typu MIM którego żądanie oczekuje, że serwer użyje go w odpowiedzi. Wyraża się to jako tipo/subtipo które można uogólnić, używając gwiazdki (*) jako znaku wieloznacznego, na przykład jako */* odnosić się do dowolnego lub tipo/* odnosić się do wszystkich podtypów tipo

  Najczęściej używane to:

  • text/plain Chociaż jest najbardziej podstawowy, jest również najczęściej używany. Oczekuje, że serwer zwróci prostą (czystą) odpowiedź tekstową, która wystarczy do powiadomienia, że ​​transakcja przebiegła prawidłowo i co najwyżej dodania dodatkowych informacji, takich jak numer porządkowy zarejestrowanych danych, wynik porównania, data serwer…

  • application/xml o text/xml Poczekaj, aż serwer odpowie na żądanie w formacie XML. Znaczenie wyboru text zamiast application pozwala na łatwiejszy „ludzki” (w porównaniu z „automatycznym”) odczyt. Ta dwoistość będzie objawiać się w innych Typy MIME ale przyszłym trendem standardu jest preferowanie application przed text Format XML pozwala na bardzo solidną strukturę odpowiedzi zawierającej dużo danych, wadą jest to, że dodaje dużo sztuczności do danych sieciowych, co sprawia, że ​​odpowiedź zajmuje więcej niż to konieczne, a zatem wymaga większej przepustowości i prawdopodobnie więcej pamięć w urządzeniu IoT w celu jej przetworzenia.

  • text/html Używane, gdy odpowiedź serwera to HTML zakodowane jako zwykły tekst (zwykły tekst), zwykle formatujący odpowiedź. Ponieważ chodzi o przechowywanie danych, a odpowiedź docierałaby do małego urządzenia bez wielu zasobów, nie jest powszechne używanie tego typu.

  • application/xhtml+xml Zasadniczo jest to wersja XHTML (HTML jako XML ważne) informacji zawartych w poprzedniej sekcji.

  • application/json Jest najczęściej używany, gdy odpowiedź serwera zawiera kilka danych o mniej lub bardziej złożonej strukturze. Format JSON udostępnij w formacie XML solidną strukturę i ma tę zaletę, że jest bardziej zwięzły w tekście dodanym przez strukturę.

• Accept-Charset Określa kodowanie tekstu, które ma być użyte w odpowiedzi. Aby zakodować znaki łacińskie, plik UTF-8, najbardziej kompletny, ISO-8859 15, który zawiera znak euro (€) i ISO-8859 1, co jest najbardziej podstawowe.

• Accept-Encoding Wskazuje format, zgodnie z którym może być kodowana odpowiedź serwera. Zasadniczo służy do wskazania rodzaju kompresji. Niektóre z najczęstszych to gzip deflate (które można określić bardziej szczegółowo za pomocą deflate-raw o deflate-http) Nie jest powszechne stosowanie go w małych urządzeniach podłączonych do Internetu rzeczy, ponieważ wymaga pewnego zużycia zasobów (pamięci i czasu przetwarzania), których zwykle brakuje w tego typu sprzęcie. Nie jest konieczne zaznaczanie, że kompresja nie jest używana Accept-Encoding: identity ponieważ taka okoliczność jest domyślnie brana pod uwagę.

• Accept-Language Określa język, jakiego można użyć w odpowiedzi. Na przykład język hiszpański w Hiszpanii będzie określony jako es-ES lub angielski Stanów Zjednoczonych Ameryki jako en-US

• Connection Służy do określenia, co należy zrobić z połączeniem, które zostało nawiązane pomiędzy klientem (urządzeniem IoT) a urządzeniem serwer internetowy po otrzymaniu danych. Zwykle używane z wartością close w formacie Connection: close aby wskazać, że połączenie powinno zostać zamknięte po udzieleniu odpowiedzi klientowi.

• Content-Length Pozwala na wskazanie ilości bajtów zajmowanych przez część żądania zawierającą dane, czyli tę znajdującą się po nagłówkach i oddzieloną pustą linią. Jest to bardzo przydatne, ponieważ służy do sprawdzenia integralności przesyłanych informacji; Jeśli nie zmierzy tego, co zostało zadeklarowane, nie jest przechowywane, ponieważ uważa się, że nie dotarło prawidłowo. Jest to zwykle wymagane przez większość publicznych serwerów IoT.

• Content-Type Służy do wskazania Typ MIME za pomocą którego szyfrowana jest informacja przesyłana do serwera. Typy są zwykle używane text/html gdy dane wysyłane na serwer są wyrażone jako prosta lista wartości (coś w stylu a=3.6&b=4.8) I application/jsonrequest (co byłoby odpowiednikiem typu application/json o którym mowa w Accept), gdy konieczna jest bardziej złożona struktura, ale można przesłać dowolne z poniższych lista typów MIME.

• Cookie Służy do dodania identyfikatora sesji, za pomocą którego można utrzymać łańcuch transferów (zapytanie, odpowiedź, zapytanie...), który jest bardziej złożony niż pojedyncze żądanie przesłania określonych powiązanych danych, ale uzyskanych w różnym czasie.

Spis treści


• Referer Adres URL, z którego pochodzi żądanie POST, na przykład strona internetowa, z której zostało ono wysłane. W przypadku wykorzystania do IoT nie dodaje istotnych informacji, ponieważ informacje są przesyłane bezpośrednio, bez poprzedniej strony, więc nie są często używane.

• User-Agent Raportuje urządzenie wysyłające żądanie. W normalnym ruchu internetowym przeglądarka wykorzystywana w Internecie Rzeczy umożliwia serwerowi wskazanie rodzaju urządzenia elektronicznego wysyłającego żądanie. Identyfikacja się z serwerem pozwala na różne formatowanie odpowiedzi w każdym przypadku, na przykład zwrócenie złożonej strony internetowej do przeglądarki i kilka danych ostrzegawczych do małego urządzenia IoT.

Możliwe jest określenie listy opcji oddzielonych przecinkami zamiast pojedynczej wartości w nagłówkach, aby wskazać, że obsługiwanych jest jednocześnie kilka różnych wartości. Wartości te mogą mieć kolejność priorytetów wyrażoną według współczynnika jakości q dla każdej z nich. Współczynniki jakości są oddzielone średnikiem (;), a gwiazdki (*) mogą być również użyte w odniesieniu do dowolnego typu lub podtypu.

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

W poprzednim przykładzie priorytet formatu JSON największa (0.9) to zwykły tekst i tekst sformatowany. XML, które spełniają specyfikację text/*, jest mniejsza (0.8) i równa między nimi. Jeśli to możliwe, serwer powinien zareagować, kodując odpowiedź jako JSON.

W poniższym przykładzie bardziej kompletnego żądania POST dostęp do strony /iot/grabar_temperatura serwera o nazwie polaridad.es uzyskuje się przy użyciu wersji 1.1 protokołu HTTP. Klient o nazwie Sensoreitor-2000 wysyła zakodowane dane JSON, spodziewaj się odpowiedzi w postaci zwykłego tekstu w formacie UTF-8 używając hiszpańskiego z Hiszpanii bez stosowania kompresji, czego, nawiasem mówiąc, nie trzeba wskazywać. Dane przesyłane do serwera zajmują 65 bajtów. W momencie wysłania odpowiedzi połączenie pomiędzy klientem a serwerem zostanie zamknięte.

Poniższy artykuł wyjaśnia jak skonfigurować bazę danych MySQL do przechowywania informacji przesyłanych przez obiekty IoT