HTTP POST リクエストを使用して IoT Web サーバーにデータを保存する

シリーズの最初の記事で説明したように IoT デバイスによって取得されたデータを保存するただし、保存されたデータはサーバー上に保存されます。 MySQL o MariaDB そして言語が使われます PHP 入出力でそれらを操作するために、電子機器とデータベース間の情報の流れは、 ウェブサーバー に従って通信する相手と HTTPプロトコル.

の定義の冒頭で、 HTTPプロトコル 説明されているものと同等の用途がありましたが、実際には、セキュリティのため、また、より具体的またはより効率的なプロトコルの定義が進歩していないため、さまざまな理由により、最終的には十分に活用されていません。パブリックサーバーでは、最も一般的なのは接続を使用することです HTTP 何がそれを作るのか POSTリクエスト サーバーに送信して情報を保存するか、 GET それを回復するには、通常、それを表示し、さらには対話できる Web ページを表示します。

リクエストでサーバーに送信される最も基本的なテキスト HTTP POST リクエストのタイプ (POST) 情報とバージョンを保存する Web ページへのパス HTTPプロトコル;ホスト名を含む別の行 (同じサーバー上および/または同じ IP アドレス上の仮想サーバーを許可します)、最後に記録されたデータを含む別の行があり、互いに & 記号で区切られ、前の行とは XNUMX つずつ区切られています。空白。

上の例では、polaridad.es というサーバーには、バージョン 1.1 を使用して情報を管理するためのページが /iot/grabar_temperatura に含まれています。 HTTPプロトコル

XNUMX つの & 記号が使用されており、XNUMX つのフィールドが保存されていることを示していることがわかります。フィールドの名前は等号の左側にあり、フィールドの定義には XNUMX 文字のみが使用されています。リクエストのフィールド (または必要に応じて変数) の名前として HTTP これらはデータベース内の名前とは関連していません。説明的なテキストを使用することは特に重要ではありません。サーバーとの通信時にテキストを保存し、データ送信プロセスを高速化するために、通常は短い名前 (偶数番号のフィールド) が選択されます。

IoT デバイスが通常サーバーに送信するデータは数値タイプで、主に整数と単純な小数です。例の変数「ne」の場合のように、値がテキスト形式で送信される場合、場合によっては、多かれ少なかれ成功して簡単に解決できる不利な状況が発生する可能性があります。この場合、単語の区切りにはプラス記号 (+) が使用され、他の方法では文字列が変更されてしまうスペースが置き換えられます。 POSTリクエスト。ほとんどの場合を解決するデータ送信の一般的な方法は、文字の XNUMX 進コードを先頭にパーセント記号 (%) を付けて指定することです。論理的には、エンコードされた内容に問題がある場合を除き、このリソースを使用することはお勧めできません。送信される内容が増加するため、通常はより多くのリソースが必要になりますが、サイズは確かに非常に小さくなります。

操作は可能ですが、 ウェブサーバー 前の例の情報のみを使用するモノのインターネットの場合、多くのサーバー、特にパブリックサーバーは、POST クエリに他のデータを追加します (残念ながら、必ずしもプロトコルに限定されるわけではありません)。以下の例は、ウェルによって要求された POST リクエストに対応します。 -既知のサーバー。モノのインターネット用のパブリック シングスピーク.

などの一部の個人データに加えて、 X-THINGSPEAKAPIKEY (各クライアントの識別子に対応します) 前の例では、リクエストにさらに情報を追加する他のヘッダーがあることがわかります。

でヘッダーを使用する方法 POSTリクエスト これは、名前、コロン記号 (:)、空白スペース、および割り当てたい値を記述するだけで構成されます。

他のコンポーネントの構成を完了する前に Web サーバーへの POST リクエストをテストするには、サーバーへの接続を確立し、データを手動で送信します。たとえば、Linux コンピュータでは、次のように使用するだけで十分です。 telnet polaridad.es 80 ここで、polaridad.es はサーバーの名前、80 はサービスが応答するポート番号です。 HTTP.

クロスプラットフォーム ツールは Linux、Windows、または OS で使用できます 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 これは、特定の関連データを送信するための単一のリクエストよりも複雑な転送チェーン (クエリ、応答、クエリ...) を維持するためのセッション ID を追加するために使用されますが、取得されるタイミングは異なります。

目次


• Referer POST リクエストを送信した URL (送信元の Web ページなど)。 IoT用途の場合は、前ページを介さずに直接情報が送信されるため、関連情報が追加されないため、使用頻度は高くありません。

• User-Agent リクエストを行っているデバイスを報告します。通常の Web トラフィックでは、モノのインターネットで使用されるブラウザにより、サーバーはリクエストを行っている電子デバイスの種類を示すことができます。サーバーに対して自身を識別することで、応答をそれぞれのケースで異なる形式にすることができます。たとえば、複雑な Web ページをブラウザーに返し、いくつかの警告データを小型 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 リクエストの例では、polaridad.es というサーバーの /iot/grabar_temperatura ページに、HTTP プロトコルのバージョン 1.1 を使用してアクセスします。 Sensoreitor-2000 と呼ばれるクライアントは、エンコードされたデータを次の形式で送信します。 JSONの、形式のプレーンテキストとしての応答が期待されます UTF-8 圧縮を使用せずにスペインのスペイン語を使用します。ちなみに、これを示す必要はありません。サーバーに送信されるデータは 65 バイトを占めます。応答を送信すると、クライアントとサーバー間の接続が閉じられます。

以下の記事で解説しています IoT オブジェクトによって送信された情報を保存するように MySQL データベースを構成する方法