API Connector

improve this page | report issue

概説

Mobile Foundation アプリケーションでは、Mobile Foundation アダプターを使用することでマイクロサービスまたはエンタープライズ・バックエンド・サービスを呼び出すことができます。アダプターの作成には、Mobile Foundation アダプター・フレームワークについての知識が必要です。Mobile Foundation では、また、アダプターを使用せずに Mobile Foundation API Connector を介してマイクロサービスまたはエンタープライズ・バックエンド・サービスに対してセキュアな呼び出しを行うことができます。API Connector は、アダプターと同様に Mobile Foundation の OAuth 2.0 メカニズムを利用したセキュアな呼び出しを保証します。API Connector を使用すると、Mobile Foundation 管理者は Mobile Foundation でマイクロサービスまたはエンタープライズ・バックエンド・サービスの詳細を構成およびデプロイできます。デプロイされた構成は、モバイル・アプリからマイクロサービスまたはバックエンド・サービスの要求をセキュアに呼び出すために、Mobile Foundation ランタイムによって使用されます。

利点

Mobile Foundation API Connector の使用には以下のような利点があります。

  • マイクロサービスと統合するための疎結合のバックエンド。
  • アプリと API の詳細な分析。
  • 単一のマイクロサービス・レイヤーを使用した、クロスチャネル・アーキテクチャー (Web、モバイル、またはその他) に対応するための Backend for Frontend (BFF) パターンとのクリーンな統合。
  • チャネルとバックエンド全体での効率的なパフォーマンス調整。
  • Mobile Foundation アダプター・テクノロジーのスキルに依存しない。
  • すぐに使用可能なアプリ管理。
  • 軽量のランタイム。
  • 拡張が容易で信頼性が高く、ユーザー・コードを必要としないランタイム。

API Connector の使用方法

API Connector を使用するには、以下の 2 ステップを実行する必要があります。

  • マイクロサービスまたはバックエンド・サービスの構成を定義して、Mobile Foundation サーバーにデプロイする。
  • デプロイされた構成を介してマイクロサービスまたはバックエンド・サービスのメソッドを呼び出すように、クライアント・アプリを変更する。

フロー

図に示すように、最初のステップでは、管理 API を使用してマイクロサービスまたはエンタープライズ・バックエンド・サービスの詳細を構成し、Mobile Foundation サーバーにデプロイします。Mobile Foundation ランタイムは、デプロイされた構成を使用して、該当するマイクロサービスまたはエンタープライズ・バックエンドに対するクライアント要求をセキュアに呼び出します。

OAuth ベースの Mobile Foundation のセキュリティー・メカニズムによって、確実に正当なアプリケーション・クライアントからの呼び出しが行われます。Mobile Foundation Client SDK と Mobile Foundation 許可サーバーは、アプリケーションにより出された要求を内部で検証します。エンタープライズ・バックエンド・サービスは、十分なセキュリティー検証のために呼び出されます。

API Connector のフロー

マイクロサービスまたはエンタープライズ・バックエンドの構成の定義とデプロイ

Mobile Foundation の管理 API を使用すると、クライアント・アプリが接続する必要があるマイクロサービスまたはエンタープライズ・バックエンドの詳細を構成してデプロイできます。そのために使用する管理 API は以下にあります。

http://<host>:<port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config

Mobile Foundation からバックエンド・サービスの詳細を管理するために、構成 API の以下のメソッドが使用可能です。

  1. バックエンド・サービス構成をデプロイする場合は POST を使用します。
  2. デプロイされたバックエンド・サービス構成を取得する場合は GET を使用します。
  3. 以前にデプロイされた構成を削除する場合は DELETEを使用します。

POST API は、JSON 形式でサービス構成の詳細を使用します。以下に構成 JSON 構文を示します。

{
"backendServices" : [
    {
        "service": "resorts",
        "baseUrl":"http://mybluemix.net/resorts",
        "auth" : {
            "type" : "basic",
            "credential" : {
                "username" : "user",
                "password" : "pass"
            }
        },
        "ConnectionProperties" : {
            "maxConnetions" : "50",
            "connectionTimeoutInMilliseconds" : "20000",
            "socketTimeoutInMilliseconds" : "20000"
        }
    }
]
}

JSON で使用されているキーについて、以下に説明します。

  1. service – マイクロサービスまたはエンタープライズ・バックエンド・サービスを識別するための論理サービス名。この管理 API を使用して Mobile Foundation サーバーに構成されたサービス・リスト内の特定のサービスで、サービス名は固有でなければなりません。
  2. baseurl – マイクロサービスまたはエンタープライズ・バックエンド・サービスの基本 URL。これはクライアント・アプリによって呼び出し可能なメソッドを公開する、マイクロサービスの完全な URL です。メソッド名は、クライアント・アプリケーションから提供されます。
  3. auth – エンタープライズ・バックエンド・サービスへのアクセスに使用される認証の詳細。
    • type – Mobile Foundation では以下の 3 つのタイプをサポートします。
      • 「基本」 – ユーザー名とパスワードを構成する「credentials」セクションを伴う基本認証。 以下に例を示します。
         "credential" : {
             "username" : "hello",
             "password" : "hello"
         }
        
      • apikey – API 鍵ベースの認証では、policy タイプに基づいてさまざまな異なるスキームがサポートされています。以下に apikey の構文を示します。
         "type" : "apikey",
         "credential" : {
             "apikey" : "abcdefg",
             "policy" : "basic",
             "name" : "apikey"
         }
        

        ポリシーは、バックエンド・サービスが想定する API 鍵 (apikey) の提示方法に応じて、headerquery、または basic に設定できます。ポリシー値に header を設定すると、name により指定されたヘッダー名とともに、要求ヘッダー内で apikey を転送します。ポリシーに query を設定すると apikey を照会パラメーターとして送信し、ポリシーに basic を設定すると apikey を基本認証として送信します。

      • mfpauth – この type では、マイクロサービスは Mobile Foundation OAuth ベースのセキュリティー・メカニズムを利用できます。credentials セクションは mfpauth タイプにおいては必須ではなく、構成 JSON に含める必要はありません。

      バックエンド・サービスは、セキュリティー・スコープ、許可サーバー、および Mobile Foundation 認証サーバーによって保護することができます。Mobile Foundation 認証メカニズムでは、バックエンド・サービスへのアクセスを提供する前に、必要なスコープを使用する有効なアクセス・トークンが確実に要求に含まれます。Mobile Foundation 認証サーバーがイントロスペクション中に提示されたアクセス・トークンの妥当性を確認すると、バックエンド・サービスへのアクセスが許可されます。Mobile Foundation 認証サーバーを使用するためのバックエンド・サービスの構成方法について詳しくは、こちらを参照してください。

      • extauth – このタイプは、外部またはサード・パーティーの認証サーバーを使用してバックエンド・マイクロサービスをサポートする場合に使用できます。アプリケーション・クライアントは、バックエンド・サービスが必要とするアクセス・トークンを、ext-token という名前の特殊ヘッダーで渡す必要があります。API Connector は、アプリ・クライアントから ext-token ヘッダーの一部として受け取ったアクセス・トークンを、Authorization ヘッダーとしてバックエンド・マイクロサービスに転送します。credential セクションは extauth タイプでは必須ではなく、構成 JSON に含める必要はありません。外部トークンのイントロスペクション、およびトークンの満了後の更新は、アプリ・クライアントとバックエンド・マイクロサービスによって処理することが必要になります。アプリ・クライアントを検証するための Mobile Foundation セキュリティー・メカニズムはそのまま使用されます。
  4. ConnectionProperties を使用すると、Mobile Foundation サーバーとバックエンド・マイクロサービス間の接続パラメーターを構成できます。これらのパラメーターはオプションであり、指定しない場合はデフォルト値が使用されます。以下に ConnectionProperties の構文を示します。 JSON "ConnectionProperties" : { "maxConnetions" : "50", "connectionTimeoutInMilliseconds" : "20000", "socketTimeoutInMilliseconds" : "20000" } 以下は、個々の接続パラメーターのデフォルト値です。
    • maxConnetions => 20
    • connectionTimeoutInMilliseconds => 30000 (つまり 30 秒)
    • socketTimeoutInMilliseconds => 30000 (つまり 30 秒)

以下に管理 API curl コマンドの構文を示します。

  1. POST: 構成をデプロイします。
     curl -X POST -u admin:admin 'http://<host>:<port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config' --header 'Content-Type: application/json' --data-binary  @config.json
    

    ここで config.json は、上記の JSON 構文と同様の構成を持つ JSON ファイルです。

  2. GET: 既存の構成をフェッチします。
     curl -X GET -u admin:admin 'http:// <host>:<port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config'
    
  3. DELETE : 既存のデプロイ済みの構成を削除します。
     curl -X DELETE -u admin:admin 'http:// <host>:<port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config'
    

マイクロサービスまたはバックエンド・サービスの構成が Mobile Foundation にデプロイされると、Mobile Foundation Client SDK を使用してエンタープライズ・バックエンド・サービスを呼び出すことができます。Client SDK API の詳細については、こちらを参照してください。

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on July 03, 2020