Armazene dados em um servidor web IoT usando solicitações HTTP POST

Conforme explicado no primeiro artigo da série armazenar dados obtidos por dispositivos da Internet das Coisas, embora os dados salvos acabem em um servidor MySQL o MariaDB e a linguagem é usada PHP para manipulá-los na entrada e na saída, o fluxo de informações entre o equipamento eletrônico e o banco de dados ocorre por meio de um servidor web com quem você se comunica de acordo com o Protocolo HTTP.

No início da definição de Protocolo HTTP Houve utilizações comparáveis ​​​​ao que está sendo descrito, mas o fato é que no final não foi totalmente explorado por várias razões, em parte de segurança e em parte porque nunca houve progresso na definição de um protocolo mais específico ou mais eficiente, então hoje em dia, especialmente em servidores públicos, o mais comum é usar uma conexão HTTP o que faz um Solicitação POST ao servidor para armazenar as informações ou um ENTRE para recuperá-lo, normalmente para exibir uma página web que o apresente e até mesmo na qual você possa interagir.

O texto mais básico enviado ao servidor em uma solicitação HTTP POST inclui uma linha com o tipo de solicitação (POST) o caminho para a página web que armazenará as informações e a versão do Protocolo HTTP; outra linha com o nome do host (que permite servidores virtuais no mesmo servidor e/ou no mesmo endereço IP) e finalmente outra que contém os dados que são gravados, separados entre si pelo sinal & e das linhas anteriores por um em branco.

No exemplo acima, um servidor chamado polaridad.es conteria uma página em /iot/grabar_temperatura para gerenciar a informação utilizando a versão 1.1 do Protocolo HTTP

Pode-se observar que são utilizados dois sinais &, o que mostra que três campos estão armazenados. O nome dos campos está à esquerda do sinal de igual e apenas duas letras foram utilizadas para defini-los. Como o nome dos campos (ou variáveis, se preferir) da solicitação HTTP Eles não estão relacionados aos do banco de dados, não é especialmente importante o uso de textos descritivos e geralmente são escolhidos nomes curtos (campos pares numerados) para salvar o texto na comunicação com o servidor e agilizar o processo de envio de dados.

Os dados que um dispositivo IoT normalmente envia ao servidor são do tipo numérico, principalmente números inteiros e decimais simples. Quando os valores são enviados em formato de texto, como é o caso da variável “ne” do exemplo, podem surgir circunstâncias desfavoráveis ​​que podem ser resolvidas, dependendo do caso, com maior ou menor sucesso e facilidade. Nesta ocasião, sinais de mais (+) são usados ​​para separar palavras, substituindo espaços que de outra forma alterariam a Solicitação POST. Uma forma genérica de envio de dados que resolve a maioria dos casos é indicando o código hexadecimal dos caracteres, precedido do sinal de porcentagem (%) Logicamente, não é aconselhável utilizar este recurso exceto quando o que está codificado é problemático, pois o comprimento do que enviado é aumentado, o que geralmente requer mais recursos, embora seja certamente de tamanho muito pequeno.

Embora seja possível operar um servidor web Para a Internet das Coisas apenas com as informações do exemplo anterior, muitos servidores, principalmente os públicos, adicionam outros dados à consulta POST (infelizmente nem sempre limitados ao protocolo). O exemplo abaixo corresponde à solicitação post solicitada pelo poço -servidor conhecido.público para internet das coisas CoisaFalar.

Além de alguns dados pessoais, como X-THINGSPEAKAPIKEY (e que corresponde ao identificador de cada cliente) no exemplo anterior você pode ver que existem outros cabeçalhos que adicionam mais informações à solicitação.

Como usar um cabeçalho em um Solicitação POST Consiste simplesmente em escrever seu nome, dois pontos (:), um espaço em branco e o valor que deseja atribuir.

Para testar as solicitações POST ao servidor web antes de concluir a configuração dos demais componentes, uma conexão com o servidor pode ser estabelecida e os dados enviados manualmente. Por exemplo, em um computador Linux seria suficiente usar telnet polaridad.es 80 onde polaridad.es é o nome do servidor e 80 é o número da porta na qual o serviço responde. HTTP.

A ferramenta multiplataforma pode ser usada em Linux, Windows ou sistema operacional PuTTY, que foi falado no artigo controlar dispositivos seriais UART do computador, para fazer a conexão sem usar o console.

Na próxima Lista de cabeçalhos HTTP Há a maioria daqueles que podem ser úteis para um Solicitação POST para uma servidor web para Internet das coisas.

• Accept É usado para indicar o tipo MIME que a solicitação espera que o servidor use na resposta. É expresso como tipo/subtipo que pode ser generalizado usando o asterisco (*) como caractere curinga, por exemplo como */* para se referir a qualquer ou tipo/* para se referir a todos os subtipos de tipo

  Os mais comumente usados ​​são:

  • text/plain Embora seja o mais básico, é também o mais utilizado. Ele espera que o servidor retorne uma resposta em texto simples (sem formatação) que seja suficiente para notificar que a transação foi correta e no máximo adicionar informações acessórias como o número do pedido dos dados registrados, o resultado de uma comparação, a data da transação servidor…

  • application/xml o text/xml Aguarde até que o servidor responda à solicitação no formato XML. O significado de escolher text em vez de application permite uma leitura “humana” (versus “automática”) mais fácil. Esta dualidade se apresentará em outros Tipos MIME mas a tendência futura do padrão é preferir application frente a text O formato XML permite que uma resposta que contém muitos dados seja estruturada de forma muito sólida, a desvantagem é que adiciona muito artifício aos dados da rede, o que faz com que a resposta ocupe mais do que o necessário, exigindo portanto mais largura de banda e provavelmente mais memória no dispositivo IoT para processá-lo.

  • text/html Usado quando a resposta do servidor é HTML codificado como texto simples (texto simples), geralmente formatando uma resposta. Por se tratar de armazenamento de dados e a resposta chegaria a um dispositivo pequeno e sem muitos recursos, não é comum a utilização deste tipo.

  • application/xhtml+xml Basicamente é a versão XHTML (HTML como XML válido) das informações da seção anterior.

  • application/json É mais utilizado quando a resposta do servidor contém vários dados incluindo uma estrutura mais ou menos complexa. O formato JSON compartilhar com formato XML uma estrutura sólida e acrescenta a vantagem de ser mais conciso no texto adicionado pela estrutura.

• Accept-Charset Determina a codificação de texto solicitada para uso na resposta. Para codificar caracteres latinos, o UTF-8, o mais completo, ISO-8859 15, que inclui o sinal do Euro (€) e o ISO-8859 1, que é o mais básico.

• Accept-Encoding Indica o formato segundo o qual a resposta do servidor pode ser codificada. Basicamente serve para indicar um tipo de compressão. Alguns dos mais frequentes são gzip deflate (que pode ser especificado com mais detalhes com deflate-raw o deflate-http) Não é comum utilizá-lo em pequenos dispositivos conectados à Internet das Coisas, pois requer um certo consumo de recursos (memória e tempo de processamento) que normalmente são escassos neste tipo de equipamento. Não é necessário indicar que a compressão não é usada com Accept-Encoding: identity uma vez que tal circunstância é considerada por padrão.

• Accept-Language Expressa a linguagem que pode ser usada na resposta. Por exemplo, o espanhol da Espanha seria especificado como es-ES ou o inglês dos Estados Unidos da América como en-US

• Connection É utilizado para especificar o que deve ser feito com a conexão que foi estabelecida entre o cliente (o dispositivo IoT) e o servidor web assim que os dados forem recebidos. Normalmente usado com o valor close no formato Connection: close para indicar que a conexão deve ser encerrada após responder ao cliente.

• Content-Length Permite indicar a quantidade de bytes ocupados pela parte da solicitação que contém os dados, que é aquela após os cabeçalhos e separados por uma linha em branco. É muito útil porque serve para verificar a integridade da informação enviada; Se não medir o que foi declarado, não é armazenado, pois se considera que não chegou corretamente. Geralmente é exigido pela maioria dos servidores IoT públicos.

• Content-Type Serve para indicar o Tipo MIME com o qual as informações enviadas ao servidor são codificadas. Os tipos são geralmente usados text/html quando os dados enviados ao servidor são expressos como uma simples lista de valores (algo como a=3.6&b=4.8) E application/jsonrequest (que seria o equivalente ao tipo application/json que é falado em Accept) quando uma estrutura mais complexa é necessária, mas qualquer um dos itens a seguir pode ser enviado lista de tipos MIME.

• Cookie É utilizado para adicionar um identificador de sessão para manter uma cadeia de transferências (consulta, resposta, consulta...) mais complexa que uma única solicitação para enviar determinados dados relacionados, mas obtidos em momentos diferentes.

Tabela de conteúdos


• Referer URL que originou a solicitação POST, por exemplo a página web da qual ela foi enviada. No caso de ser utilizado para IoT, não agrega informações relevantes, pois as informações são enviadas diretamente, sem página anterior, por isso não são utilizadas com frequência.

• User-Agent Informa o dispositivo que está fazendo a solicitação. No tráfego normal da web, o navegador utilizado na Internet das Coisas permite ao servidor indicar o tipo de dispositivo eletrônico que faz a solicitação. A identificação para o servidor permite que a resposta seja formatada de forma diferente em cada caso, por exemplo, retornando uma página web complexa para um navegador e alguns dados de aviso para um pequeno dispositivo IoT.

É possível especificar uma lista de opções separadas por vírgula em vez de um único valor nos cabeçalhos para indicar que vários valores diferentes são suportados simultaneamente. Esses valores podem ter uma ordem de prioridade que se expressa de acordo com um coeficiente de qualidade q para cada um. Os coeficientes de qualidade são separados por ponto e vírgula (;) e asteriscos (*) também podem ser usados ​​para se referir a qualquer tipo ou subtipo.

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

No exemplo anterior a prioridade do formato JSON o maior (0.9) é o do texto simples e o do texto formatado. XML, que atendem à especificação text/*, é menor (0.8) e igual entre eles. Se possível, o servidor deve reagir codificando a resposta como JSON.

No exemplo a seguir de uma solicitação POST mais completa, a página /iot/grabar_temperatura do servidor chamada polaridad.es é acessada usando a versão 1.1 do protocolo HTTP. O cliente, denominado Sensoreitor-2000, envia os dados codificados em JSON, espere a resposta como texto simples no formato UTF-8 usar o espanhol da Espanha sem usar compressão, o que, aliás, não é necessário indicar. Os dados enviados ao servidor ocupam 65 bytes. Ao enviar a resposta a conexão entre o cliente e o servidor será encerrada.

O artigo a seguir explica como configurar banco de dados MySQL para armazenar informações enviadas por objetos IoT