このトピックでは、IoT Platform がサポートする Message Queuing Telemetry Transport（MQTT）5.0 のリクエストレスポンスパターンについて説明します。
背景情報
MQTT のパブリッシュ/サブスクライブパターンでは、メッセージは非同期的に公開および受信され、パブリッシャーとサブスクライバーは分離されています。IoT デバイスの実際のビジネスシナリオの中には、サブスクライバーからの応答が必要なものがあります。このような場合は、リクエストレスポンスパターンを使用できます。たとえば、サーバーがデバイスの電源をオンまたはオフにするコマンドを送信したり、デバイスがサーバーにデータのリクエストを送信したりする場合などです。
機能説明
MQTT 5.0 のリクエストレスポンスパターンは、HTTP リクエストレスポンスパターンとは異なり、非同期の要求メッセージと応答メッセージを使用します。応答メッセージをリクエストメッセージに関連付けるために、リクエストメッセージには Response Topic と Correlation Data が追加されます。これにより、レスポンダー側の開発が簡素化されます。
Response Topic: レスポンダーが応答メッセージを公開する Topic を指定する文字列です。
Correlation Data: リクエストのコンテキストを格納するバイナリデータです。レスポンダーはこのデータを使用して、リクエストメッセージを識別できます。
次の図は、リクエストレスポンスパターンを使用した場合のメッセージングプロセスを示しています。
デバイスに同時に複数のリクエストを送信する場合、各リクエストメッセージの Correlation Data にリクエスト ID を含めることができます。これにより、レスポンダーはリクエストを識別できます。
IoT Platform は、revert-remote procedure call（RRPC）通信をサポートしています。リモートデバイスをリアルタイムで制御する場合は、RRPC を使用して応答を同期的に取得できます。
QoS 1 メッセージは IoT Platform によって受信される必要があります。サブスクライバーがメッセージを受信し、メッセージで必要な操作を完了できるようにするには、リクエストレスポンスパターンの使用をお勧めします。
シナリオ
デバイスがサーバーにデータをリクエストする
シナリオによっては、IoT デバイスがサーバーにデータをリクエストする必要があります。たとえば、スマート調理機器がクラウドからさまざまなレシピをリクエストし、さまざまな種類のレシピが別々の Topic に保存されているとします。リクエストレスポンスパターンを使用すると、サーバーは Topic を区別することなく、レシピで応答するだけで済みます。これにより、サーバー側の開発が簡素化されます。
デバイスは、リモートコントロールのシナリオと同様に、Correlation Data を使用してリクエストメッセージと応答メッセージを関連付けることができます。
サーバーは、デバイスによってリクエストされたデータのみで応答し、応答メッセージが属する Topic を識別しません。
サーバーがリモートデバイスを制御する
サーバーがリモートデバイスにコマンドを送信する場合、サーバーはすぐに応答を受信することを期待します。たとえば、サーバーが電子錠のロックを解除するコマンドを送信するとします。このシナリオでは、リクエストレスポンスパターンを使用でき、デバイス ID 情報を Correlation Data に含めてデバイスを認証できます。
