Skip to content

REST API

EMQXはOpenAPI(Swagger)3.0仕様に準拠したHTTP管理APIを公開しています。

EMQXはREST APIを探索・操作するための複数の方法を提供しています。EMQX起動後、以下のAPI仕様エンドポイントが利用可能です。

エンドポイントフォーマット説明
/api-spec.htmlHTML人間が読みやすいドリルダウン形式のAPIリファレンスページ。
/api-spec.mdMarkdownAIエージェントや自動化ツールに適したMarkdown形式のAPIリファレンス。
/api-spec.jsonJSONスクリプトやプログラム的ツールに適したOpenAPI 3.0仕様のJSON形式。
/api-docs/index.htmlHTMLブラウザ上で直接APIコールをテスト可能なインタラクティブなSwagger UI。非推奨:v7で削除予定。

上記のすべてのエンドポイントは、ダッシュボード設定でswagger_supporttrue(デフォルト)に設定されている必要があります。falseに設定すると、すべてのAPIドキュメントエンドポイントが無効になります。詳細はダッシュボード設定をご参照ください。

本節ではEMQX REST APIの利用方法について説明します。

基本パス

EMQXのREST APIはバージョン管理されており、EMQX 5.0.0以降のすべてのAPIパスは/api/v5で始まります。

HTTPヘッダー

ほとんどのAPIリクエストでは、Acceptヘッダーにapplication/jsonを設定する必要があります。特に指定がない限り、レスポンスはJSON形式で返されます。

HTTPレスポンスステータスコード

EMQXはHTTPレスポンスステータスコード標準に準拠しています。主なステータスコードは以下の通りです。

コード説明
200リクエスト成功。返却されるJSONデータに詳細が含まれます。
201作成成功。新規オブジェクトがBodyに返されます。
204リクエスト成功。通常は削除や更新操作で、返却Bodyは空です。
400不正なリクエスト。リクエストボディやパラメータのエラー。
401認証失敗。APIキーが期限切れまたは存在しません。
403禁止。オブジェクトが使用中、または依存制約があります。
404見つかりません。Bodyのmessageフィールドで理由を確認可能。
409競合。オブジェクトが既に存在するか、数の制限を超過。
500サーバ内部エラー。Bodyやログで原因を確認してください。

認証

EMQXのREST APIは主に2つの認証方法をサポートしています。APIキーを用いたベーシック認証とベアラートークン認証です。

APIキーを用いたベーシック認証

この方法では、APIキーとシークレットキーをユーザー名とパスワードとして使用し、APIリクエストを認証します。EMQXのREST APIはHTTPベーシック認証に準拠しており、これらの認証情報が必要です。EMQX REST APIを使用する前に、APIキーを作成する必要があります。

注意

セキュリティ上の理由から、EMQX 5.0.0以降はダッシュボードのユーザー認証情報をREST API認証に使用できません。代わりにAPIキーを作成し、認証に使用してください。

APIキーの作成

ダッシュボードのシステム -> APIキーから手動でAPIキーを作成できます。詳しくはシステム - APIキーをご参照ください。

また、ブートストラップファイル方式でAPIキーを作成することも可能です。以下の設定ファイルを追加し、ファイルの場所を指定します。

bash
api_key = {
  bootstrap_file = "etc/default_api_key.conf"
}

指定したファイル内に複数のAPIキーを以下の形式で改行区切りで記述します。

{API Key}:{Secret Key}:{?Role}
  • API Key: 任意の文字列でキー識別子。
  • Secret Key: ランダムな文字列をシークレットキーとして使用。
  • Role(任意): キーのロールを指定。

例:

bash
my-app:AAA4A275-BEEC-4AF8-B70B-DAAC0341F8EB
ec3907f865805db0:Ee3taYltUKtoBVD9C3XjQl9C6NXheip8Z9B69BpUv5JxVHL:viewer
foo:3CA92E5F-30AB-41F5-B3E6-8D7E213BE97E:publisher

この方法で作成されたAPIキーは無期限で有効です。

EMQX起動時にファイル内のデータがAPIキーリストに追加されます。既存のAPIキーがある場合は、シークレットキーとロールが更新されます。

ロールと権限

REST APIはロールベースアクセス制御を実装しています。APIキー作成時に以下の3つの事前定義ロールのいずれかを割り当てられます。

  • administrator(管理者): すべてのリソースにアクセス可能。ロール未指定時のデフォルト。
  • viewer(閲覧者): リソースやデータの閲覧のみ可能。REST APIのすべてのGETリクエストに対応。
  • publisher(パブリッシャー): MQTTメッセージのパブリッシュに特化し、メッセージパブリッシュ関連APIのみアクセス可能。

APIキーを用いた認証方法

APIキーとシークレットキーを取得したら、ベーシック認証のユーザー名にAPIキー、パスワードにシークレットキーを指定してリクエストを認証できます。

各言語での例:

ベアラートークン認証

APIキー認証の代替として、ベアラートークンを使用してEMQX REST APIに安全かつプログラム的にアクセスできます。ベアラートークンを取得するには、以下のログインAPIエンドポイントにリクエストを送信します。

ベアラートークンの取得

ベアラートークンを取得するには、以下のログインAPIエンドポイントにHTTP POSTリクエストを送信します。

bash
POST http://your-emqx-address:8483/api/v5/login

ヘッダー:

  • Content-Type: application/json

リクエストボディ:

json
{
  "username": "admin",
  "password": "yourpassword"
}
  • your-emqx-addressはEMQXノードのアドレスまたはIPに置き換えてください。
  • "admin""yourpassword"はEMQXダッシュボードの認証情報に置き換えてください。

レスポンスにはベアラートークンが含まれ、APIリクエストの認証に使用できます。

ベアラートークンを用いた認証

ベアラートークン取得後、APIリクエストのAuthorizationヘッダーに以下のようにトークンを含めてください。

bash
--header "Authorization: Bearer <your-token>"

ページネーション

大量のデータを扱う一部APIではページネーション機能が提供されています。データの特性に応じて2種類のページネーション方式があります。

ページ番号によるページネーション

ページネーション対応APIの多くは、page(ページ番号)とlimit(ページサイズ)パラメータでページングを制御します。最大ページサイズは10000です。limitが指定されない場合、デフォルトは100です。

例:

bash
GET /clients?page=1&limit=100

レスポンスのmetaフィールドにページネーション情報が含まれます。EMQXは検索条件付きリクエストの総データ数を予測できないため、meta.hasnextフィールドで次ページの有無を示します。

json
{
  "data":[],
  "meta":{
    "count":0,
    "limit":20,
    "page":1,
    "hasnext":false
  }
}

カーソルによるページネーション

データが急速に変化し、ページ番号によるページネーションが非効率な一部APIではカーソルページネーションを採用しています。

positionまたはcursor(開始位置)パラメータでデータの開始位置を指定し、limit(ページサイズ)パラメータで開始位置から読み込む件数を指定します。最大ページサイズは10000で、limit未指定時は100です。

例:

bash
GET /clients/{clientid}/mqueue_messages?position=1716187698257189921_0&limit=100

レスポンスのmetaフィールドにページネーション情報が含まれ、meta.positionまたはmeta.cursorが次ページの開始位置を示します。

json
{
    "meta": {
        "start": "1716187698009179275_0",
        "position": "1716187698491337643_0"
    },
    "data": [
        {
            "inserted_at": "1716187698260190832",
            "publish_at": 1716187698260,
            "from_clientid": "mqttx_70e2eecf_10",
            "from_username": "undefined",
            "msgid": "000618DD161F682DF4450000F4160011",
            "mqueue_priority": 0,
            "qos": 0,
            "topic": "t/1",
            "payload": "SGVsbG8gRnJvbSBNUVRUWCBDTEk="
        }
    ]
}

この方式はデータの変動が激しい場合に効率的かつ連続的なデータ取得を実現します。

エラーコード

HTTPレスポンスステータスコードに加え、EMQXは特定のエラーを識別するためのエラーコード一覧を定義しています。

エラー発生時は、BodyにJSON形式でエラーコードが返されます。

bash
# GET /clients/foo

{
  "code": "RESOURCE_NOT_FOUND",
  "reason": "Client id not found"
}
エラーコード説明
WRONG_USERNAME_OR_PWDユーザー名またはパスワードが間違っています
WRONG_USERNAME_OR_PWD_OR_API_KEY_OR_API_SECRETユーザー名&パスワードまたはキー&シークレットが間違っています
BAD_REQUESTリクエストパラメータが不正です
NOT_MATCH条件が一致しません
ALREADY_EXISTSリソースが既に存在します
BAD_CONFIG_SCHEMA設定データが不正です
BAD_LISTENER_IDリスナーIDが不正です
BAD_NODE_NAMEノード名が不正です
BAD_RPCRPC失敗。クラスター状態と対象ノードの状態を確認してください
BAD_TOPICトピック構文エラー。トピックはMQTTプロトコル標準に準拠する必要があります
EXCEED_LIMIT作成しようとしたリソースが最大または最小制限を超えています
INVALID_PARAMETERリクエストパラメータが不正または境界値を超えています
CONFLICTリクエストリソースが競合しています
NO_DEFAULT_VALUEリクエストパラメータがデフォルト値を使用していません
DEPENDENCY_EXISTSリソースが他のリソースに依存しています
MESSAGE_ID_SCHEMA_ERRORメッセージIDの解析エラー
INVALID_IDIDスキーマが不正です
MESSAGE_ID_NOT_FOUNDメッセージIDが存在しません
NOT_FOUNDリソースが見つかりません
CLIENTID_NOT_FOUNDクライアントIDが見つかりません
CLIENT_NOT_FOUNDクライアントが見つかりません(通常はMQTTクライアントではありません)
RESOURCE_NOT_FOUNDリソースが見つかりません
TOPIC_NOT_FOUNDトピックが見つかりません
USER_NOT_FOUNDユーザーが見つかりません
INTERNAL_ERRORサーバ内部エラー
SERVICE_UNAVAILABLEサービス利用不可
SOURCE_ERRORソースエラー
UPDATE_FAILED更新失敗
REST_FAILEDリセットソースまたは設定の失敗
CLIENT_NOT_RESPONSEクライアントが応答しません