Menu Close

1.3. API の初期設定

本セクションでは、API トラフィックを API キーで保護し、追跡し、3scale に設定した基本的な流量制御および管理機能で監視するための初期設定について、概要を説明します。3scale の操作が初めてであれば、ウィザードを実行して 最初の API を容易に設定することができます。

1.3.1. 新規プロダクトの作成

プロダクトは顧客がアクセスする API で、1 つまたは複数のバックエンドが含まれています。本セクションでは、プロダクトを 3scale に追加する方法について説明します。

以下のオプションのどちらかに従って、新規プロダクトを作成することができます。

  • 手動でプロダクトを定義する。
  • OpenShift からプロダクトをインポートする。

本セクションでは、手動での定義について詳細に説明します。OpenShift からプロダクトをインポートする場合には、『管理ポータルガイド』の「サービスディスカバリー」を参照してください。

前提条件

  • 3scale アカウントが必要です。

手順

  1. Dashboard に移動します。
  2. APIS セクションで Products タブを選択します。
  3. New Product をクリックします。
  4. 以下の情報を指定します。

    • Name: プロダクトの識別子
    • System name: 内部での処理に使用される識別子。プロダクトの system_name を使用して、プロキシーエンドポイントおよびドメイン名が生成されます。デフォルトでは、system_name はラベルの一部で、ラベルのパターンは以下のどちらかになります。

      • ステージング環境用 APIcast の場合: %{system_name}-%{tenant_name}-apicast-staging
      • 実稼働環境用 APIcast の場合: %{system_name}-%{tenant_name}-apicast-production

        OpenShift が Zync により作成されるルートを許可するには、ラベルの文字数を最大でも 63 文字にする必要があります (パターン内のダッシュを含む)。したがって、system_name を指定する場合、前述したパターンの文字数の制限を考慮する必要があります。

    • Description: プロダクトに関するより詳しい情報を記述するオプションフィールド
  5. Create Product をクリックします。

これらの手順を完了すると、一般に公開される API となるプロダクトが作成されます。次のステップは、バックエンドを作成し プロダクトに追加する ことです。

1.3.2. 新規バックエンドの作成

バックエンドは、プロダクトに結び付けられる内部 API です。本セクションでは、バックエンドを作成してそれをプロダクトに追加する方法について説明します。

前提条件

  • 3scale アカウントが必要です。

手順

  1. Dashboard に移動します。
  2. APIS セクションで Backends タブを選択します。
  3. New Backend をクリックします。
  4. 以下の情報を指定します。

    • Name: バックエンドの識別子
    • System name: 内部での処理に使用される識別子
    • Description: バックエンドに関するより詳しい情報を記述するオプションフィールド
    • Private endpoint: プライベート API のベース URL
  5. Create Backend をクリックします。

これらの手順を完了すると、内部 API が作成されます。必要なだけのバックエンドを追加することができます。次のステップは、このバックエンドをプロダクトに追加する ことです。

1.3.3. プロダクトへのバックエンドの追加

本セクションでは、プロダクトへのバックエンドの追加について説明します。プロダクトに追加する各バックエンドについて、この手順を繰り返すことができます。

前提条件

手順

  1. Dashboard の [Your_product_name] から、Integration > Backends の順に移動します。
  2. Add Backend をクリックします。
  3. ドロップダウンリストから既存のバックエンドを選択します。
  4. Path テキストボックスでルーティングパスを指定します。詳細については、「バックエンドパス」を参照してください。
  5. Add to Product をクリックします。

これらの手順を完了すると、プロダクトにバックエンドが追加されます。プロダクトにバックエンドをさらに追加する、あるいは別のプロダクトにバックエンドを追加する場合には、再度この手順を実施することができます。

バックエンドパス

バックエンドをプロダクトに追加する場合、その特定のプロダクトに関してバックエンドが使用するパスを定義します。このパスは、バックエンドの一部ではありません。

「プロダクトへのバックエンドの追加」に記載の手順から、APIcast はステップ 4 で指定したバックエンドのパスを使用します。APIcast はリクエストされたエンドポイントパスを前方一致で照合し、指定したパスを使用してトラフィックをバックエンドにリダイレクトします。

バックエンドのパスを定義する際の留意事項は以下のとおりです。

  • バックエンドの 1 つのパスとして、/ を指定することができます。
  • 1 つのプロダクト内では、パスは一意でなければなりません。つまり、1 つのプロダクト内では、同じパスを使用して 2 つのバックエンドを追加することはできません。また、1 つのプロダクトに、同じバックエンドを 2 回追加することもできません。
  • プロダクトが異なっていれば、1 つのバックエンドに同じパスを指定することができます。

バックエンドパスが機能する仕組みを以下に示します。

  • プロダクトに追加されたそれぞれのバックエンドは、指定したパスにマウントされます。
  • トラフィックをリダイレクトする前に、プロダクトに対するリクエストの公開 URL からパスが削除されます。

プロダクトにバックエンドを追加する以下の構成について考えます。

  • バックエンド: Inventory
  • リソースパス: /list
  • プロダクト: Petstore
  • バックエンドパス: /supplies

この構成で使用される URL は以下のとおりです。

  • 公開 URL: <public-api-domain>/supplies/list
  • プライベート URL: <private-api-domain>/list

リクエストが送信された際のアクションのフローを以下に示します。

  1. アプリケーションがリクエストを送信する。
  2. リクエストが公開 URL <public-api-domain>/supplies/list に送信される。
  3. プライベート URL <private-api-domain>/list にリダイレクトする前に、バックエンドパスが削除される。
  4. リクエストが Inventory バックエンドにリダイレクトされる。

1.3.4. マッピングルールの定義

本セクションでは、バックエンドレベルでのマッピングルールの定義について説明します。マッピングルールは、バックエンドレベルおよびプロダクトレベルで定義することができます。バックエンドレベルでマッピングルールを定義することのメリットは、任意のプロダクトに追加することのできる再使用可能なバックエンドを作成できることです。(プロダクトレベルおよびバックエンドレベルの両方で) API に対するリクエストに応じてレポートするメトリクスまたはメソッドの詳細については、『API ゲートウェイの管理』の「マッピングルール」を参照してください。

前提条件

手順

  1. Dashboard から Backends タブを選択します。
  2. 設定を行うバックエンドの名前をクリックします。たとえば、API Backend をクリックします。
  3. バックエンドについての詳細が表示されるページで、Mapping Rules に移動します。
  4. Add Mapping Rule をクリックします。
  5. 以下の設定を指定します。

    • Verb: HTTP リクエストの動詞 (GET、POST、DELETE、または PUT)
    • Pattern: 照合するパターン。たとえば、/hello 等。
    • Metric or method to increment: メトリクスまたはメソッドの名前
    • Increment by: メトリクスのカウントを増やす数。たとえば、1 等。
    • Last?: このマッピングルールを最後のルールとして、他のマッピングルールの処理を停止するかどうかを定義します。
    • Position: マッピングルール実行の順番を表す数字。マッピングルールの並べ替えに使用します。
  6. Create Mapping Rule をクリックします。

これらの手順を完了すると、バックエンドにマッピングルールが追加されます。このマッピングルールは、現在そのバックエンドを使用している各プロダクトでも利用することができます。マッピングルールをプロダクトレベルでアクティブにするには、プロダクトの Integration ページで最新のプロキシー設定をプロモートします。

最新のプロキシー設定をプロモートすると、3scale はバックエンドに設定されたマッピングルールをプロダクトレベルでアクティブ化します。マッピングルールは、プロダクトで指定したバックエンドパスに続きます。たとえば、以下に示す設定の場合には、

  • バックエンドでのマッピングルールのパターン: /thousands
  • バックエンドをプロダクトに追加する際のパス: /unitprice

最終的なプロダクトレベルでのマッピングルールは、/unitprice/thousands となります。

1.3.5. アプリケーションプランの作成

本セクションでは、API に基本的なアプリケーションプランを作成する方法について説明します。アプリケーションプランにより、API の使用に対するルール (制限、課金、および機能) をプロダクトレベルで定義します。詳細については、『管理ポータルガイド』の「アプリケーションプラン」および「API の定義 (メソッドおよびメトリクス)」を参照してください。

前提条件

手順

テスト用に新たなアプリケーションプランを作成するには、以下の手順に従います。

  1. [Your_product_name] > Applications > Application Plans の順に移動します。
  2. Create Application Plan をクリックします。
  3. Create Application Plan のページで、新しいプランの名前およびシステム名を入力します。

    • システム名は一意でなければなりません。
  4. Create Application Plan をクリックします。

1.3.6. アプリケーションの作成

本セクションでは、デフォルトの Developer アカウントに基本的なアプリケーションを作成する手順の概要を説明します。

アプリケーションはアプリケーションプランを参照します。アプリケーションは、必ずアプリケーションプランに関連付けられます。アプリケーションは、開発者アカウント内に保管されます。3scale の Basic プランで許可されるアプリケーションは 1 つだけですが、Enterprise プランではアカウントごとに複数のアプリケーションが許可されます。

前提条件

手順

  1. Dashboard > Audience > Account の順に移動します。
  2. Developer というデフォルトアカウントをクリックします。
  3. Application タブに移動します。
  4. Create Application をクリックします。
  5. アプリケーションプランを選択します。
  6. 名前および説明を指定します。
  7. Create Application をクリックします。

1.3.7. プロダクトを含めたバックエンドのテスト

本セクションでは、バックエンドがどのようにプロダクトに接続されるか、およびその接続の確認方法について説明します。プロダクトを含めたバックエンドのテストでは、リクエストコールを元にテストを行うために、APIcast 設定をステージング環境および実稼働環境にプロモートする必要があります。

プロダクトに対するリクエストは、パスに従って対応するバックエンドにリダイレクトされます。このパスは、バックエンドをプロダクトに追加する際に設定されます。たとえば、プロダクトに 2 つのバックエンドを追加している場合、それぞれのバックエンドは固有のパスを持ちます。

前提条件

手順

  1. [Your_product_name] > Integration > Configuration の順に移動して、APIcast 設定をステージング環境にプロモートします。
  2. APIcast Configuration セクションに、プロダクトに追加された各バックエンドのマッピングルールが表示されます。Promote v.[n] to Staging APIcast をクリックします。

    • v.[n] は、プロモートされるバージョン番号を表します。
  3. ステージング環境にプロモートしたら、実稼働環境にプロモートすることができます。Staging APIcast セクションで、Promote v.[n] to Production APIcast をクリックします。

    • v.[n] は、プロモートされるバージョン番号を表します。
  4. コマンドラインで API へのリクエストをテストするには、Example curl for testing で提供されるコマンドを使用します。

    • curl コマンドの例は、プロダクトの最初のマッピングルールに基づいています。

API へのリクエストをテストする際に、メソッドおよびメトリクスを追加して マッピングルールを変更することができます。

設定を変更したら、API への呼び出しを行う前に、必ずステージング環境および実稼働環境にプロモートするようにしてください。ステージング環境にプロモートする保留中の変更がある場合には、管理ポータルの Integration メニュー項目の横に感嘆符が表示されます。

1.3.8. その他の参考情報

プロダクトおよびバックエンドについての詳細は、以下のアーティクルを参照してください。