Stocker des données sur un serveur Web IoT à l'aide de requêtes HTTP POST

Comme expliqué dans le premier article de la série stocker les données obtenues par les appareils Internet des objets, même si les données enregistrées finissent sur un serveur MySQL o MariaDB et la langue est utilisée PHP pour les manipuler en entrée et en sortie, le flux d'informations entre l'équipement électronique et la base de données s'effectue à l'aide d'un serveur web avec qui vous communiquez selon les Protocole HTTP.

Au début de la définition de Protocole HTTP Il y a eu des utilisations comparables à celle décrite, mais le fait est qu'en fin de compte, elle n'a pas été pleinement exploitée pour diverses raisons, en partie pour la sécurité et en partie parce que des progrès n'ont jamais été réalisés dans la définition d'un protocole plus spécifique ou plus efficace. sur les serveurs publics, le plus courant est d'utiliser une connexion HTTP qu'est-ce qui fait un Requête POST au serveur pour stocker les informations ou un ÉCONOMISEZ pour le récupérer, normalement pour afficher une page web qui le présente et même sur laquelle vous pouvez interagir.

Le texte le plus basique envoyé au serveur dans une requête HTTP POSTEZ comprend une ligne avec le type de demande (POSTEZ) le chemin d'accès à la page Web qui stockera les informations et la version du Protocole HTTP; une autre ligne avec le nom d'hôte (qui autorise les serveurs virtuels sur le même serveur et/ou sur la même adresse IP) et enfin une autre qui contient les données enregistrées, séparées les unes des autres par le signe & et des lignes précédentes par un vide.

Dans l'exemple ci-dessus, un serveur appelé polaridad.es contiendrait une page dans /iot/grabar_temperatura pour gérer les informations en utilisant la version 1.1 du Protocole HTTP

On peut voir que deux signes & sont utilisés, ce qui montre que trois champs sont stockés. Le nom des champs se trouve à gauche du signe égal et seules deux lettres ont été utilisées pour les définir. Comme nom des champs (ou variables, si vous préférez) de la requête HTTP Ils ne sont pas liés à ceux de la base de données, il n'est pas particulièrement important d'utiliser des textes descriptifs et des noms courts sont généralement choisis (champs pairs) pour enregistrer le texte en communication avec le serveur et accélérer le processus d'envoi des données.

Les données qu'un appareil IoT envoie normalement au serveur sont de type numérique, principalement des nombres entiers et de simples décimales. Lorsque des valeurs sont envoyées au format texte, comme c'est le cas avec la variable "ne" dans l'exemple, des circonstances défavorables peuvent survenir qui peuvent être résolues, selon les cas, avec plus ou moins de succès et de facilité. A cette occasion, des signes plus (+) sont utilisés pour séparer les mots, remplaçant les espaces qui autrement modifieraient le Requête POST. Une manière générique d'envoyer les données qui résout la plupart des cas consiste à indiquer le code hexadécimal des caractères, précédé du signe de pourcentage (%). Logiquement, il n'est pas conseillé d'utiliser cette ressource sauf lorsque ce qui est codé pose problème car la longueur de ce qui est envoyé est augmenté, ce qui nécessite généralement plus de ressources, même si sa taille est certainement très réduite.

Bien qu'il soit possible d'exploiter un serveur web Pour l'Internet des Objets uniquement avec les informations de l'exemple précédent, de nombreux serveurs, notamment publics, ajoutent d'autres données à la requête POST (malheureusement pas toujours limitées au protocole). L'exemple ci-dessous correspond à la requête post demandée par le puits -serveur connu. public pour l'Internet des objets ChoseParle.

Outre certaines données personnelles, telles que X-THINGSPEAKAPIKEY (et qui correspond à l'identifiant de chaque client) dans l'exemple précédent vous pouvez voir qu'il existe d'autres en-têtes qui ajoutent plus d'informations à la requête.

Comment utiliser un en-tête dans un Requête POST Cela consiste simplement à écrire son nom, un signe deux-points (:), un espace et la valeur que vous souhaitez lui attribuer.

Afin de tester les requêtes POST au serveur web avant de terminer la configuration des autres composants, une connexion au serveur peut être établie et les données envoyées manuellement. Par exemple, sur un ordinateur Linux, il suffirait d'utiliser telnet polaridad.es 80 où polaridad.es est le nom du serveur et 80 est le numéro de port sur lequel le service répond. HTTP.

L'outil multiplateforme peut être utilisé sous Linux, Windows ou OS PuTTY, dont on a parlé dans l'article contrôler les périphériques série UART depuis un ordinateur, pour établir la connexion sans utiliser la console.

Dans ce qui suit Liste des en-têtes HTTP Il y en a la plupart qui peuvent être utiles pour un Requête POST un serveur web pour l'Internet des objets.

• Accept Il est utilisé pour indiquer le type MIME que la requête s'attend à ce que le serveur utilise dans la réponse. Il s'exprime comme tipo/subtipo qui peut être généralisé en utilisant l'astérisque (*) comme signe générique, par exemple comme */* faire référence à un ou tipo/* pour désigner tous les sous-types de tipo

  Les plus couramment utilisés sont :

  • text/plain Bien que ce soit le plus basique, c’est aussi le plus utilisé. Il attend du serveur qu'il renvoie une réponse simple en texte (en clair), suffisante pour notifier que la transaction a été correcte et tout au plus ajouter des informations accessoires telles que le numéro d'ordre des données enregistrées, le résultat d'une comparaison, la date de l'enregistrement. serveur…

  • application/xml o text/xml Attendez que le serveur réponde à la demande au format XML. Le sens de choisir text au lieu de application permet une lecture « humaine » (par opposition à « automatique ») plus facile. Cette dualité se présentera chez d'autres Types MIME mais la tendance future de la norme est de préférer application Frente a text Le format XML permet de structurer de manière très solide une réponse qui contient beaucoup de données, l'inconvénient est que cela ajoute beaucoup d'artifice aux données nettes, ce qui fait que la réponse prend plus que nécessaire, nécessitant donc plus de bande passante et probablement plus mémoire dans l’appareil IoT pour le traiter.

  • text/html Utilisé lorsque la réponse du serveur est HTML codé sous forme de texte brut (texte brut) formatant généralement une réponse. Puisqu’il s’agit de stocker des données et que la réponse parviendrait à un petit appareil sans beaucoup de ressources, il n’est pas courant d’utiliser ce type.

  • application/xhtml+xml En gros c'est la version XHTML (HTML comme XML valide) des informations de la section précédente.

  • application/json Il est surtout utilisé lorsque la réponse du serveur contient plusieurs données incluant une structure plus ou moins complexe. Le format JSON partager avec le format XML une structure solide et ajoute l'avantage d'être plus concis dans le texte ajouté par la structure.

• Accept-Charset Détermine le codage de texte qui doit être utilisé dans la réponse. Pour coder des caractères latins, le UTF-8, le plus complet, ISO-8859 15, qui comprend le signe euro (€) et le ISO-8859 1, qui est le plus basique.

• Accept-Encoding Indique le format selon lequel la réponse du serveur peut être encodée. Fondamentalement, cela sert à indiquer un type de compression. Certains des plus fréquents sont gzip deflate (qui peut être précisé plus en détail avec deflate-raw o deflate-http) Il n'est pas courant de l'utiliser dans de petits appareils connectés à l'Internet des objets car il nécessite une certaine consommation de ressources (mémoire et temps de traitement) qui sont généralement rares dans ce type d'équipements. Il n'est pas nécessaire d'indiquer que la compression n'est pas utilisée avec Accept-Encoding: identity puisqu'une telle circonstance est considérée par défaut.

• Accept-Language Exprime le langage qui peut être utilisé dans la réponse. Par exemple, l'espagnol d'Espagne serait spécifié comme es-ES ou l'anglais des États-Unis d'Amérique comme en-US

• Connection Il est utilisé pour spécifier ce qu'il faut faire avec la connexion qui a été établie entre le client (l'appareil IoT) et le serveur web une fois les données reçues. Généralement utilisé avec la valeur close au format Connection: close pour indiquer que la connexion doit être fermée après avoir répondu au client.

• Content-Length Il permet d'indiquer le nombre d'octets occupés par la partie de la requête qui contient les données, qui est celle située après les en-têtes et séparée par une ligne vide. C'est très utile car il sert à vérifier l'intégrité des informations envoyées ; S'il ne mesure pas ce qui a été déclaré, il n'est pas stocké car on considère qu'il n'est pas arrivé correctement. Il est généralement requis par la plupart des serveurs IoT publics.

• Content-Type Il sert à indiquer le Type MIME avec lequel les informations envoyées au serveur sont codées. Les types sont généralement utilisés text/html lorsque les données envoyées au serveur sont exprimées sous la forme d'une simple liste de valeurs (quelque chose comme a=3.6&b=4.8) Y application/jsonrequest (ce qui serait l'équivalent du type application/json dont on parle dans Accept) lorsqu'une structure plus complexe est nécessaire, mais que l'un des éléments suivants peut être envoyé liste des types MIME.

• Cookie Il est utilisé pour ajouter un identifiant de session avec lequel maintenir une chaîne de transferts (requête, réponse, requête...) plus complexe qu'une seule requête avec laquelle envoyer certaines données liées mais obtenues à des moments différents.

Table des matières


• Referer URL à l'origine de la requête POST, par exemple la page Web à partir de laquelle elle a été envoyée. Dans le cas d'une utilisation pour l'IoT, il n'ajoute pas d'informations pertinentes puisque les informations sont envoyées directement, sans page précédente, elles ne sont donc pas fréquemment utilisées.

• User-Agent Signale l'appareil qui fait la demande. Dans le trafic Web normal, le navigateur utilisé dans l'Internet des objets permet au serveur d'indiquer le type d'appareil électronique effectuant la demande. S'identifier auprès du serveur permet de formater la réponse différemment dans chaque cas, par exemple en renvoyant une page Web complexe à un navigateur et quelques données d'avertissement à un petit appareil IoT.

Il est possible de spécifier une liste d'options séparées par des virgules au lieu d'une valeur unique dans les en-têtes pour indiquer que plusieurs valeurs différentes sont prises en charge simultanément. Ces valeurs peuvent avoir un ordre de priorité qui s'exprime selon un coefficient de qualité q pour chacune. Les coefficients de qualité sont séparés par un point-virgule (;) et des astérisques (*) peuvent également être utilisés pour désigner n'importe quel type ou sous-type.

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

Dans l'exemple précédent la priorité du format JSON le plus grand (0.9) est celui du texte brut et celui du texte formaté. XML, qui répondent aux spécifications text/*, est plus petit (0.8) et égal entre eux. Si possible, le serveur doit réagir en codant la réponse comme JSON.

Dans l'exemple suivant d'une requête POST plus complète, la page /iot/grabar_temperatura du serveur appelé polaridad.es est accessible en utilisant la version 1.1 du protocole HTTP. Le client, appelé Sensoreitor-2000, envoie les données codées dans JSON, attendez la réponse sous forme de texte brut au format UTF-8 en utilisant l'espagnol d'Espagne sans utiliser de compression, ce qui n'est d'ailleurs pas nécessaire de l'indiquer. Les données envoyées au serveur occupent 65 octets. Lors de l'envoi de la réponse, la connexion entre le client et le serveur sera fermée.

L'article suivant explique comment configurer la base de données MySQL pour stocker les informations envoyées par les objets IoT