APIルーティング
APIGWは、API単位のルーティングリソースを管理します。すべてのルーティングリソースは、アクションパイプラインを保有し、リクエストとレスポンスのメッセージに様々な加工を行うことができます。また、カスタムスクリプトを埋め込んでマイクロワークフローを駆動させることでステートレスなマッシュアップを実現することもできます。
以下はアクションパイプラインの機能配置図です。

経路選択アルゴリズム
API Gatewayは、リクエストを受信したときにルーティング戦略を計画します。リクエストヘッダと起動パラメータは、次のルーティング戦略を決定します。

| Strategy | Condition | description |
|---|---|---|
| Delegate | 起動パラメータ--force_delegation_mode=True |
上位のAPIGatewayに転送します。 |
| Direct | X-Xaas-Direct-Routingが指定されている |
X-Xaas-Direct-Routingで指定されたURLに転送します。v25.1LTSでサポートを停止しました。 |
| Static | X-Xaas-Static-Routingが指定されている |
ルートエントリのターゲットエンドポイントをX-Xaas-Static-Routingで指定されたエンドポイントに変換します。 |
| Tunneling | X-Xaas-Tunnelingが指定されている |
カプセル化されたリクエスト本文からヘッダ、パラメータ、本文をデコードして新しいHTTPリクエストを作成し、ルートエントリのターゲットエンドポイントに転送します。 |
| Standard | 経路制御拡張ヘッダが含まれていない | ルートエントリのターゲットエンドポイントに転送します。 |
| Hierarchical | ルーティング未定義で且つ--hierarchical_routing_mode=True |
上位のAPIGatewayに転送します。 |
Note
リクエストパスに一致するルートエントリは、パスの階層ごとに、名前が完全に一致する固定のセグメントを持つルートを変数セグメント({id}等)のルートより先に評価して決まります(v26.1LTS以降)。固定のセグメントの側で一致するルートが見つからない場合は、従来どおり残りのルートから判定します。
例えば、/devices/{id}と/{kind}/searchが登録されている場合、/devices/searchへのリクエストは登録順に依らず/devices/{id}にルーティングされます。
Scenarioのuri(組込みAPIを含む)も同様に、階層の数が同じ場合は、先頭のセグメントから順に比べて固定のセグメントを持つものが変数セグメントのものより先に評価されます。
Tip
リージョナルなサービスのエンドポイントがターゲットの場合、APIルーティングにエンドポイントを固定化できないため、Scenarioなどのプラグインでエンドポイントを選定してX-Xaas-Static-RoutingにセットしてAPI Gatewayに送信することで動的にターゲットを切り替える手法が最適です。ScenarioからのcalloutにX-Xaas-Static-Routing拡張ヘッダを埋め込む方法は、リファレンス>>組込関数のcalloutを参照してください。
Note
-
Tunnelingを利用する場合、X-Xaas-Tunneling拡張ヘッダにはスーパーAPI鍵を指定する必要があります。 -
DelegateとHierarchicalは、起動パラメータで上位のAPI Gatewayを指定しておく必要があります。--superior_apigw_host={host} --superior_apigw_port={port}
Tip
標準ルーティングStandardはVRF機能が適用されます。柔軟なエンドポイントスイッチングは、複数のDevOps環境で役立ちます。
ルーティングプレーンは、GUIを使用していつでも簡単に変更できます。
また、実稼働環境などで誤ってVRF切替が発生しないようにプレーンを固定したい場合は、以下のように起動パラメータで指定してください。
Ex) --plane=prod
アクションパイプライン
APIルーティングはリクエスト、レスポンスに対する様々なアクションを適用できるアクションパイプラインを持ちます。アクションパイプラインで利用できる各機能ブロックを以下に解説しています。
Out of service
API閉塞を制御する機能です。閉塞状態でリクエストを受信した場合に返却する応答はカスタマイズできます。デフォルトでは503 Service Unavailableが返却されます。
Tip
OUSブロックを通過した後、X-Xaas-Schedule-Datetimeがリクエストヘッダで指定されている場合、それはスケジュールサービスにWebフック予約されます。時間形式は%Y-%m-%d%H:%M:%Sです。つまり、APIGWに登録されているすべてのAPIは、絶対時刻を指定する予約可能なAPIになります。予約されたリクエストに対する応答は、202 Acceptedで応答本文には、予約IDが格納されます。予約の前にルートの認可が行われ、認可に失敗した場合は予約されず401/403が返ります。
In service time
APIが稼働する時間を制限できる機能です。設定された開始時刻と終了時刻の間のアクセスのみを許可し、アクセスが許可されていない時間帯は、503 Service Unavailableを応答します。応答コードや本文は、Out of service機能にデフォルトのOUS応答を設定することでカスタマイズすることもできます。
Proxy authorization
リクエスト認可を行う機能です。BASIC認証、Digest認証、Keystone認証、およびQmonus独自認証をサポートしています。
Pop header
指定されたキーに合致するリクエストヘッダを除去する機能です。
Push header
指定されたヘッダをリクエストヘッダに追加する機能です。
Queuing
リクエストをキューイングして非同期化する機能です。
Note
キューの設定パラメータは次のとおりです。
enable: キューイングを有効にするかどうかを指定します。デフォルトはFalseです。
queue_type: キュータイプは、serialとparallelの2つのタイプから選択できます。serialでは、1つのワーカーがキューを消費し、一度に1つのタスクをシリアルで処理します。parallelの場合、複数のワーカーがキューを消費し、タスクを並行して処理します。parallelの場合、各ワーカーは起動パラメーター--parallel_queue_bulk_read_sizeで指定された数までタスクをデキューし、それらをまとめて処理します。APIGWが2コア3クラスターおよび--parallel_queue_bulk_read_size=32で実行されている場合、2 * 3 * 32 = 192多重で動作します。
max_residence_time: キュー内の最大滞留時間を秒単位で指定します。この秒数を超えてキューにとどまると、破棄されます。
accept_response: 開発者がキューイング後の応答をカスタマイズしたい場合に、HTTP応答コードと本文を設定できます。
accept_responseを指定しない場合、次のデフォルトの応答が返されます。
type: object
required:
- taskid
- status
- content
properties:
taskid:
type: string
description: The identifier of the queued task.
status:
type: string
description: Task processing status
content:
type: object
properties:
registration_time:
description: Entry time to the task queue
type: string
max_residence_time:
description: Maximum residence time
type: integer
expire_time:
description: Expiration time
type: string
request:
type: object
properties:
url:
type: string
headers:
type: object
method:
type: string
body:
type: string
description: Queued HTTP request content
Tip
デフォルトの応答に含まれるtaskidで実行されたタスクの応答を取得できます。ただし、max_residence_timeを超えるとタスクの応答が消えるので、設定には注意が必要です。
タスクの実行結果は、以下のAPIで取得できます。
GET /queues/{taskid}
GET /queues/{taskid}の応答は、上記のデフォルトの202 Accepted応答と同じスキーマです。
タスクステータス値の意味は次のとおりです。
Waiting: まだ待ち行列にあります
Processing: タスクは処理中です
Processed: タスクが処理されました
Discarded: タスクは破棄されました
参考: キューイングと消費の基本シーケンス図

Target authentication
ターゲットへの認証を代行する機能です。BASIC認証、Digest認証、Keystone認証、OAuth認証、AWS-HMAC-V4認証、およびQmonus独自認証をサポートします。
Warning
ターゲットがhttpsの場合、v26.1LTS以降はtarget.validate_certのデフォルトがTrueになり、ターゲットのサーバ証明書とホスト名が検証されます(v25.2LTS以前はFalse)。自己署名証明書やプライベートCAの証明書を使うターゲットでは、target.validate_cert: falseを指定するか、target.ca_certsでCA証明書を指定してください。X-Xaas-Static-Routingでhttpsのエンドポイントに切り替えた場合や、キューイングしたリクエストも、ルートの設定に従います。httpのターゲットには影響しません。
Stub(非推奨)
APIモック応答を作成できる機能です。将来のリリースで削除される予定です。後述するforbidden_processでよりきめ細かいモック作成が可能です。
Body template(非推奨)
テンプレートエンジンを使用して本文をレンダリング結果に書き換える機能です。Scenarioサービスのtemplateプラグインを使用することもできます。本機能はforbidden_processまたはBody mapperで代替できるため、将来削除予定です。
templateに直接記述したテンプレートでは、埋め込む文字列の値をJSONの文字列としてエスケープします(v26.1LTS以降)。出力はJSONを前提としているため、XMLなどJSON以外を出力する場合は値に|eを付けてください。値をJSONとして埋め込む場合は、引用符で囲まずに|tojsonを使用してください(例: {"name": {{ params.name|tojson }}})。
Forbidden process
リクエストとレスポンスを開発者のカスタムスクリプトにフックし、自由にカスタマイズできる機能です。詳細は、APIGWにおけるプログラミングを参照してください。
Body key filter
1ライナーのカスタムスクリプトまたはホワイトリスト、ブラックリストに従って、本文内のキーをフィルタリングできる機能です。
Body mapper
Parametermapperサービスを適用して本体を整形できる機能です。
Convert body style
本文のキースタイルを変換する機能です。snake caseからlower camel caseへの変換または、その逆変換をサポートします。
Body validation schema
jsonschemaによる本文のバリデーション検査を提供する機能です。v26.1LTS以降、リクエスト本文をJSONとして解釈した値を検証します(v25.2LTS以前は本文をそのまま検証していました)。JSONとして解釈できない場合やスキーマに一致しない場合は、400 Bad Requestを応答します。本文が空の場合はnullとして検証します。
Lambda proxy(非推奨)
リクエストをlambdaイベントに変換して発行し、処理結果で応答する機能です。本機能はforbidden_processで代替できるため、将来削除予定です。
Note
v26.1LTS以降、処理結果が辞書またはリストの場合はJSONで応答します。JSONとして解釈できない文字列の場合は、XMLとして解釈できればapplication/xml; charset=UTF-8、それ以外はtext/plain; charset=UTF-8で文字列をそのまま応答します(v25.2LTS以前はJSON文字列として応答していました)。
また、lambdaのハンドラが例外やタイムアウトで終了した場合はチェインの結果が500として記録されるため、同期モードのLambda proxyは500を応答します。
Lambda hook(非推奨)
リクエスト/レスポンス時にlambdaイベントを発生させる機能です。本機能はforbidden_processで代替できるため、将来削除予定です。
Error body off
ターゲットからの応答がエラーの場合に、本体を空にする機能です。ターゲットに接続できない場合(599)も本体を空にします。ステータスコードは変わりません。
APIの認証スコープについて
APIルーティングにはscope属性があり、secure、 local、publicの3種類から指定できます。secureモードの場合は、Qmonus認証認可が有効化されます。起動パラメータ--local_scope_auth_modeがTrueの場合、localモードにはQmonus認証認可が必要になります。 Falseおよびpublicモードの場合、Qmonus認証認可は無効化されます。
| スコープ | Qmonus認証認可 |
|---|---|
| secure | enable |
| local | enable if options.local_scope_auth_mode==True else disable |
| public | disable |
Caution
X-Xaas-Static-Routing拡張ヘッダはsecureスコープでのみ有効です。
またv25.2LTS-patch20261023以降、このヘッダはaxis内部からの呼び出しであることを示すX-Xaas-Family-Keyが
一致する場合にのみ採用されます。外部クライアントが直接指定したものは無視され、ルートエントリの設定どおりに
ルーティングされます(Scenarioからのcalloutは内部呼び出しのため従来どおり利用できます)。