サブアプリ API の呼び出し

App supervisorEnterprise Edition+

マルチアプリでは、各サブアプリが独立した API を持ちます。サブアプリ API を呼び出すには、入口アプリにどのサブアプリへルーティングするかを知らせる必要があります。

たとえば、メインアプリの API は通常次のようになります。

GET /api/users:list

/api はデフォルトの API プレフィックスで、環境変数 API_BASE_PATH で変更できます。

同じ API をサブアプリで呼び出す場合は、リクエスト内でサブアプリ名を指定します。

パスプレフィックスを使用する

/api/__app/<appName>/ プレフィックスを使用します。

GET /api/__app/a_xxx/users:list

ここで:

  • a_xxx はサブアプリ名
  • users:list は呼び出すリソースとアクション
  • /api は現在のシステムの API ベースパス

クエリパラメータも通常通り追加できます。

GET /api/__app/a_xxx/users:list?page=1&pageSize=20

この方法は分かりやすく、マルチ環境デプロイで入口アプリ経由の統一アクセスに適しています。

リクエストヘッダーで指定する

呼び出し側が固定の /api/... アドレスを使う場合、X-App ヘッダーでサブアプリを指定できます。

curl \
  -H "X-App: a_xxx" \
  http://localhost:13003/api/users:list

バックエンドサービス呼び出しや、フロントエンドのリクエストツールで API URL が共通化されている場合に適しています。

クエリパラメータで指定する

__appName クエリパラメータでも指定できます。

GET /api/users:list?__appName=a_xxx

他のパラメータと一緒に渡すこともできます。

GET /api/users:list?__appName=a_xxx&page=1&pageSize=20

通常は、対象サブアプリがより明確なパスプレフィックスまたはヘッダーを推奨します。

マルチ環境での API アドレス

マルチ環境では、通常 1 つの入口アプリと複数の実行環境があります。

例:

  • 入口アプリ:http://localhost:13003
  • 実行環境:http://localhost:14000

サブアプリ API は入口アプリ経由で呼び出すことを推奨します。

GET http://localhost:13003/api/__app/a_xxx/users:list

入口アプリはアプリ設定に基づいて対象サブアプリへルーティングします。アクセス先の実行環境が明確な場合は、その環境のアドレスも利用できます。

GET http://localhost:14000/api/__app/a_xxx/users:list

サブアプリの独自ドメイン

サブアプリに独自ドメインがある場合、そのドメインから直接 API を呼び出すこともできます。

GET https://app-example.example.com/api/users:list

入口アプリ経由に統一する場合は、引き続き /api/__app/<appName>/... を使用します。

認証

サブアプリ API の権限チェックは、対象サブアプリを基準に行われます。

つまり:

  • サブアプリで有効なログイン状態またはアクセストークンが必要です
  • メインアプリのログイン状態は、サブアプリの API 権限と自動的には同等になりません

有効な認証情報がない場合、サブアプリは自身の認証設定に従って未ログインまたは権限なしのエラーを返します。