パブリッシャー

検索
ColdFusion

ColdFusion

アプリを開く

概要

パブリッシャーとして、あらゆるサービスまたはアプリケーションから使用するための API を作成および公開できます。サブスクライバーは、API をアプリケーションで使用できます。ポータルを使用すると、API を設計して、ライフサイクル全体にわたってインタラクティブに API を管理できます。利用者とコラボレーションしたり、開発者と連携して、API を起動および実行させるために必要な重要な情報およびインサイトを収集します。

API Manager ポータルにパブリッシャーとしてログインすると、次のオプションが表示されます。

ロールの切り替え

API Manager 管理者によって複数のロール（パブリッシャーとサブスクライバーなど）が割り当てられている場合、ロールを切り替えることで、パブリッシャーとしてログインすることも、サブスクライバーとしてログインすることもできます。

REST API の作成

API Manager で REST API を作成するには、次の手順に従います。

  1. 「REST API を作成」をクリックします。基本設定ページが表示されます。

  2. 「基本設定」セクションで、次の詳細を入力します。

    フィールド

    説明

    API 名

    新しい API の名前。API を作成したら、名前は変更できません。

    コンテキスト

    サービスリクエストのコンテキストを定義します。リソースは、URI 名で階層的に表示され、アプリケーションで活用するために、利用者にわかりやすく簡単に理解できるリソースの階層が提供されます。

    説明

    API の説明。

    表示設定

    あるロールが他のユーザーによる API を表示および変更できないようにします。API を公開するモードを、パブリック、イントラネットまたはパートナーから選択します。パブリックモードでは、すべてのレベルのユーザーが API を確認できます。

    バージョン

    API のバージョン。API には、複数のバージョンが含まれることがあります。バージョンは、常に v または V から始まり、整数または小数が続く必要があります。また、バージョンは、v または V なしで始めることができます。例えば、

    デフォルトにする

    API バージョンをデフォルトにする場合に、このチェックボックスを選択します。同じ API の複数のバージョンがある場合、いずれかをデフォルトに選択できます。

    ライフサイクル

    API の進行度。ドラフト、公開済み、非推奨または廃止から選択します。

  3. API エンドポイントを定義します。エンドポイントは、Web サービスのアドレスを定義します。REST および SOAP サービスの両方を公開して、API で使用できます。「エンドポイント」セクションで、次の詳細を入力します。

  4. エンドポイントのタイプを HTTP URL またはロードバランサーから選択するには、「エンドポイント」をクリックします。

  5. ロードバランサーを選択する場合、負荷分散アルゴリズムを選択します。

    API Manager が使用する負荷分散アルゴリズムには 2 種類あります。

    • ラウンドロビン：この手法では、負荷は、API エンドポイントにわたって順番に分散されます。すべてのエンドポイントは、同じ負荷を割り当てられます。また、エンドポイントは、同じパフォーマンスです。「別のエンドポイントを追加」をクリックして、負荷を配分するエンドポイント URL を追加します。

    • 重みづけされたラウンドロビン：この手法では、負荷は、各エンドポイントに割り当てることのできる「weightage（加重値）」要素に応じて、エンドポイントにわたってバランスが取られます。負荷は、割り当てられた重みを単位として分割されます。3 つのエンドポイントに割り当てられた重みがそれぞれ 100、50、50 の場合、最初のエンドポイントは、2 番目および 3 番目のエンドポイントの 2 倍のリクエストを処理します。次の例では、
      • 最初のエンドポイントは、最初の 2 つのリクエストを処理します。
      • 2 番目のエンドポイントは、3 番目のリクエストを処理します。
      • 3 番目のエンドポイントは、4 番目のリクエストを処理します。

  6. 新しく作成した REST API のキャッシュを有効にするには、「キャッシュ機能」をクリックします。API をキャッシュすることのメリットは、速度と、サーバー負荷軽減にあります。「キャッシュ機能を有効にする」チェックボックスを選択して、キャッシングのタイムアウトを秒単位で入力します。

    リソースレベルでキャッシュ機能を有効にするには、「すべてのリソースに適用」チェックボックスを選択します。 リソースレベルのキャッシュ機能は、API にリクエストが来るたびに、個別のバックエンド呼び出しを避けて、認証タイプおよびリソースのスロットルレベルをチェックします。

  7. API のクロスオリジンリソース共有（CORS）を有効にするには、「CORS」をクリックします。CORS によって、API の制限されたリソースに他のドメインからアクセスできます。CORS は、外部ドメイン由来のリソースとやり取りするために Web ページで実行された JavaScript 呼び出しを許可する標準メカニズムです。すべての既知のブラウザーは、このポリシーを強制します。

    CORS について詳しくは、CORS を参照してください。

リソースの API への追加

「リソース」セクションで、API をリソースに分割できます。これらのリソースは、GET、PUT、POST などの各メソッドがその仕様に従って実行される HTTP リクエストを使用してアクセスまたは操作できます。

リソースは、通常、タイプおよびそれを操作するメソッドを含むオブジェクトとして定義されます。

リソースは、コレクションにグループ分けできます。また、コレクションの外部に存在するシングルトンリソースもあります。

リソースを新しい API に追加するには：

  1. 「エンドポイントのパス」フィールドに、リソースの名前を入力します。例えば、エンドポイント URL がオンラインストアを表す場合、次のリソースを定義できます。

    • /products。例：http://endpointurl/products
    • /orders。例：http://endpointurl/orders
    • ネストされた orders、{orderId}/status。例：http://endpointurl/{orderId}/status

  2. 「ニックネーム」フィールドに、API の説明を入力します。ニックネームは、API を一言で説明するものです。リソースは、ニックネームを識別子として使用します。例えば、ニックネーム /checkPhone をリソース /CheckPhoneNumber に割り当てることができます。

  3. URL の HTTP メソッドを選択して、リクエストを行います。

  4. 新しいリソースを追加するには、「リソースを追加」をクリックします。HTTP メソッドを持つリソースが、マッピングされた名前（リソースに与えられた名前）と共に表示されます。

  5. HTTP メソッドをクリックして、戻り値のタイプ、認証タイプ、頻度制限、API のスコープを変更します。

    また、API リソースのスコープを変更することもできます。

  6. クエリーパラメーターを API パスに追加して、プロパティを変更します。

  7. 出力形式または応答を定義するには、「モデルを管理」をクリックします。応答形式を追加または変更し、リソースの戻り値の型を作成できます。

リクエストと応答への圧縮方法の追加

圧縮とは、冗長な情報を削除し、必要な情報をできるだけ少ないデータ領域で表現することです。Web アプリケーションから情報を取得する速度は、ほとんどの場合、送信しようとしている情報の量に依存しているので、圧縮は、 Web で情報を送信するうえで、非常に役に立ちます。

サブスクライバーは圧縮したリクエストを送信でき、エンドポイントも 圧縮した 応答を送り返すことができます。

API リソースをパブリッシュする間、リソースが圧縮をサポートしているかどうかと、その圧縮方法を指定します。gzip か deflate のどちらかの圧縮方法を使用できます。

圧縮方法を追加するには：

  1. 編集モードでリソースのプロパティを開きます。

  2. リクエストのエンコーディングドロップダウンリストとレスポンスのエンコーディングドロップダウンリストから、適切な圧縮タイプを選択します。

  3. 「保存」をクリックします。

  4. API を試用するには、「この API をテスト」をクリックします。試用モードで、ヘッダーを更新し、API を呼び出します。

サブスクライバーは、API を呼び出すときに、これらのエンコーディングヘッダーを渡す必要があります。エンコードされたパラメーターを渡すために、サブスクライバーは、エンコーディングの種類を指定する「Content-encoding」ヘッダーを渡す必要があります。以下に示すのは、「リクエストのエンコーディング」の値の 1 つです。

次のように、content-encoding が選択した圧縮方法として表示されます。

応答の圧縮

サーバーでは、圧縮した応答を送信する必要がある場合、content-encoding ヘッダーを設定し、専用のデータ圧縮方法を使用する必要があります。それには、「レスポンスの圧縮を有効化」チェックボックスを選択します。

API を保存してテストします。

リクエストヘッダーには Accept-encoding ヘッダーが含まれており、一連のエンコーディング値がそこに指定されます。

リクエストと応答のロギング

API によって実行されたリクエストと応答をすべて、/ColdFusion_2016_install_directory/logs 内にある apimanager-trace.log ファイルに記録します。

API のリクエスト／応答ロギング機能を使用すると、API Manager からバックエンドサービスへのリクエストおよび応答パケットを追跡できます。

API によって実行されたリクエストと応答をすべて、/ColdFusion_2016_install_directory/logs 内にある apimanager-trace.log ファイルに記録します。

ロギングは、API レベルとリソースレベルのどちらでも有効にできます。

次のスクリーンショットは、API レベルでのロギングの有効化／無効化を示しています。

次のスクリーンショットは、リソースレベルでのロギングの有効化／無効化を示しています。

注意：

この設定の変更後、API Manager を再起動する必要はないので、運用が容易です。

サーバーレベルでロギングを有効にするには、管理者ポータルでログの「Dispatcher」オプションを有効にします。

また、<API Manager インストールディレクトリ>/conf 内にある log4j2.xml のログ設定を変更することもできます。xml のセクションでポリシーの間隔とサイズを変更します。

<RollingRandomAccessFile name="requesttrace-log" fileName="${log-path}/apimanager-trace.log"
                     filePattern="${log-path}/apimanager-trace-%d{yyyy-MM-dd}-%i.log">
            <PatternLayout>
                <pattern>[%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] - %msg%n</pattern>
            </PatternLayout>
            <Policies>
                <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
                <SizeBasedTriggeringPolicy size="10 MB"/>
            </Policies>
 </RollingRandomAccessFile>

Swagger スキーマからサンプル JSON データの生成

サブスクライバーが API をより詳細に理解できるように、モデルを用いて各 API のリクエストと応答を定義できます。各モデルは名前、タイプ、スキーマで構成されます。

API Manager のこのリリースでは、指定されたスキーマからサンプルデータを生成できます。

そのサンプルデータが表示される新しいテキスト領域があります。次に例を示します。

Swagger や ColdFusion などから API をインポートするために、指定されたスキーマからこのサンプルデータが自動的に生成されます。

パ ブリッシャー は、スキーマを変更し、「サンプルを生成」ボタンをクリックすることで、サンプルを生成し直すこともできます。

API の動作確認

API を作成したら、API をテストして応答や他の詳細を確認できます。左側のパネルの「この API をテスト」をクリックします。

パラメーターの値を入力し、出力形式を選択します。「API 呼び出しを実行」をクリックします。次のように、応答の詳細が表示されます。

注意：

API のテスト中に、

「API を試用する前に、プロファイルに移動して、試用キーを生成してください。」というメッセージが表示された場合は、

プロファイルに移動し、「Regenerate tryout key（試用キーを再生成）」をクリックして試用キーを取得した後で、API をテストできます。

すべての API の表示

このページでは、次のすべての API を表示できます。

  • 公開済み
  • ドラフトとして作成済み
  • 非推奨の項目
  • 廃止

また、API 可視性に従って、API のリストをフィルターできます。例えば、次のようになります。

  • 公開
  • パートナー
  • イントラネット

API カタログ

このページでは、可視性と時間（最新または最古）に従って、すべての API をフィルターできます。

管理者ポータルのヘッダー領域にあるロゴおよびタイトルを変更できます。

<API Manager Installation Directory>/wwwroot/portal/conf フォルダーに移動して、config.json ファイルを開きます。次のプロパティを変更します。

{

"headerTitle": "API Manager Portal",

"adminHeaderTitle": "API Manager Administrator",

"headerLogoPath": "images/CF-Logo.png"

}

クロスオリジンリソース共有（CORS）

CORS によって、API の制限されたリソースに他のドメインからアクセスできます。CORS は、外部ドメイン由来のリソースとやり取りするために Web ページで実行された JavaScript 呼び出しを許可する標準メカニズムです。すべての既知のブラウザーは、このポリシーを強制します。

許可される HTTP メソッド - 許可された HTTP メソッドのリスト（例：GET、PUT、POST など）。

許可される元の場所 - リクエストの元の場所または * を表します。クロスドメインを許可するリクエストについて、「許可される元の場所」で指定されたヘッダーをリクエストに追加します。例えば、サーバーが許可される元の場所を http://examplerest.com として応答すると、http://examplerest.com からのリクエストのみが許可されます。

注意：Access-Control-Allow-Origin ヘッダーには、ブラウザーからこの API を使用できる元の場所のリストが含まれています。また、このヘッダーにはワイルドカード値 * を追加することもできます。これにより、すべての Web サイトがこの API を呼び出し、応答を取得できるようになります。インターネットの外部 Web サイトの一部で、イントラネットゾーンに含まれる API を使用できるようになるなど、ワイルドカード値が誤って使用される場合があります。

許可される HTTP ヘッダー - 使用できるカスタムリクエストヘッダーのリスト（例：Origin、Content-Type など）。

（許可される公開ヘッダー - 明示的な許可を与えるヘッダーを指定して、クライアントがそれらのヘッダーを読み取れるようにします。これによって、クライアントがクロスオリジンリクエストをトリガーできます。

プリフライトの最長時間 - ブラウザーがリクエストの応答をキャッシュするまでの時間（秒単位）を指定します。

例

例えば、http://examplerest.com から http://api.examplerest.com/user のデータを GET したいとします。リクエストを認証するために承認ヘッダーに渡すことができるアクセストークン xyz123 があります。

ブラウザーは、次のヘッダーと共に OPTIONS リクエストをサーバーに送信します。

OPTIONS /user

Origin: http://www.examplerest.com

Access-Control-Request-Method: GET

Access-Control-Request-Headers: Authorization

リクエストを許可したいので、次のヘッダーでリクエストに応答します。

Allowed-Origin: http://www.examplerest.com

Allowed HTTP Headers: AUTHORIZATION

Allowed HTTP Methods: GET

ブラウザーは、GET リクエストを API がホストされているサーバーに送信します。

キャッシュ

新しく作成した REST API のキャッシュを有効にするには、「キャッシュ機能」をクリックします。API をキャッシュすることのメリットは、速度と、サーバー負荷軽減にあります。「キャッシュ機能を有効にする」チェックボックスを選択して、キャッシングのタイムアウトを秒単位で入力します。

SOAP エンドポイントから REST エンドポイントへの変換

ColdFusion SOAP サービスを REST サービスに変換するには、「Create REST API from SOAP（SOAP から REST API を作成）」をクリックします。

  1. 「一般情報」セクションで、次のような新しい API 情報を入力します。

    • API 名
    • コンテキスト
    • 表示
    • バージョン
    • 説明
    • WSDL URL

  2. 「WSDL URL」フィールドに、SOAP CFC URL を入力します。

    この例の WSDL URL には、単一のポートタイプがあります。WSDL <portType> 要素は、Web サービス、実行できる操作、関連するメッセージを定義します。

    この WSDL には、単一のバインディングがあります。WSDL バインディングは、Web サービスのメッセージの形式とプロトコルの詳細を定義します。この場合、axis1.cfcSoapBinding がバインディングです。

    soap:binding element には、style と transport の 2 つの属性があります。style 属性は、rpc または document のどちらかになります。

    transport 属性は、SOAP 転送プロトコルの名前空間を提供します。

    例えば、transport="http://schemas.xmlsoap.org/soap/http" は、SOAP over HTTP を表します。

  3. 「フェッチ」をクリックします。REST リソースにマッピングされた WSDL リソースを表示できます。ポートタイプを選択します。

  4. WSDL マッピングウィザードでは、Axis1 ポートタイプのすべての操作のリストを表示できます。

    リストからメソッドを展開します。メソッドの REST パスが、MIME タイプおよびメソッドタイプ（GET、PUT、POST など）と共に表示されます。

    メソッドタイプ POST または PUT の操作について、この操作に関連付ける引数のパラメーターのタイプを選択します。

    • PATHPARAM は、URL のパスパラメーターを示します。例えば、メソッドGET /directory/{directoryName} では、{directoryName} が PATHPARAM です。
    • QUERYPARAM は、クエリー文字列のパラメーターを示します。例えば、/search?q=johndoe です。
    • FORMPARAM は、Web フォームパラメーターを REST サービスに挿入します。

  5. REST リソースを生成するには、「REST エンドポイントを生成」をクリックします。 公開したら、API の名前を変更することはできません。

    変換後に、REST エンドポイントが表示されます。新しい URL を次に示します。

    変換後に、REST エンドポイントが表示されます。新しい URL を次に示します。

    次のように URL を使用できます。

    swagger リソースリストドキュメントを表示するには、ブラウザーのアドレスバーに次を入力します。

    次を確認できます。

    ルートリソースパスドキュメントを表示するには、アドレスバーに次を入力します。

    次を確認できます。

  6. 「SLA プラン」セクションで、API 用の 1 つまたは複数のプランを選択します。

  7. また、「リソース」セクションに、REST に変換されるすべての SOAP 操作のリストがあります。メソッドを各操作と共に確認できます。

  8. 「パブリッシュ」をクリックして、サブスクライバーが REST API を使用できるようにします。

注意：

SOAP から REST 機能は、次の WS-* SOAP 仕様をサポートしていません。

  • WS-Addressing
  • WS-Policy
  • WS-ResourceProperties
  • WS-Security
  • WS-Transactions
  • WS-ReliableMessaging
  • WS-ResourceLifetime
注意：

一部の SOAP サービスでは、そのままでは REST に変換されないリソースは、独自のメカニズムを記述して REST に変換します。

ColdFusion からの REST API のインポート

ColdFusion サーバーから REST API をインポートする前に、サーバーを設定します。詳しくは、CF Discovery の設定を参照してください。

日付を返す CF サービスを設定します。cfc で、メソッド GET および REST パスを使用します（例：/GetCurrentDate）。ColdFusion サーバーの Web ルートにフォルダーを作成して、cfc を保存します。

  1. Create API（API を作成）画面で、「（ColdFusion から）REST API をインポート」をクリックします。

  2. CF サービスのリストを表示して、CF サーバーからインポートしたいサービスの「インポート」をクリックします。

  3. cfc で定義したリソースを生成したら、SLA プランおよび API の認証方法を設定します。API を公開するには、「パブリッシュ」をクリックします。

Swagger からの REST API のインポート

Swagger は、API ドキュメントおよびサンドボックスを構築し、API クライアントのコードを生成するための仕様およびフレームワークです。

ColdFusion API Manager では、Swagger 仕様に基づく REST リソースをインポートおよび公開できます。

  1. API を作成画面で、「（Swagger から）REST API をインポート」をクリックします。

    Swagger 仕様を含める方法には、次の 3 つがあります。

    1. Swagger リンクを使用する。
    2. Swagger テキストを使用する。
    3. コンピューターから Swagger 仕様をインポートする。ファイルのアップロード後、ファイルを編集して保存することができます。変更を加えても、元のファイルには反映されません。

  2. Swagger API を入力します。この例では、Petstore サーバーを使用します。「インポート」をクリックします。

    Swagger のインポート
    Swagger のインポート

  3. API 情報を入力し、表示を設定します。

  4. API の認証タイプを設定します。

  5. 既存の Petstore リソースを表示するかリソースを追加するには、画面の左側のパネルにある「リソース」をクリックします。

  6. API を公開するには、「パブリッシュ」をクリックします。

SOAP API のインポート

API Manager のプロキシを使用して SOAP API を渡すことができます。次の操作が可能です。

  • SOAP Web サービスに対するセキュリティ認証の適用
  • レート制限の適用
  • スロットルの適用
  • 指標およびログ情報の収集

パブリッシャーとして、プロキシ WSDL URL への WSDL URL を入力します（ここで、サブスクライバーは変更された URL をプロキシ SOAP エンドポイントおよび XSD の場所と共に取得します）。

プロキシ WSDL の例：http://service.adobe.com/<API name>/<version>/?wsdl

Web サーバーまたは特定の IP の背後に SOAP プロキシをホストする場合、管理者ポータルでドメイン URL を変更します。SOAP エンドポイントは、管理者が「ドメイン URL」フィールドで定義したドメインにあります。

サブスクライバーは、プロキシエンドポイントを使用してリクエストを送信し、リクエストは実際のエンドポイントにマッピングされます。

  1. API Manager で、「SOAP API をインポート」をクリックします。

  2. 画面に詳細を入力します。API 表示設定を「公開」に設定します。「WSDL URL」フィールドに WSDL URL を入力します。例えば、「WSDL URL」に "http://www.thomas-bayer.com/axis2/services/BLZService?wsdl" と入力します。

    この WSDL は、ドイツの銀行の銀行ソートコード（Bank BLZ コード）をフェッチするのに使用できる Web サービスのリクエストおよびレスポンスを生成します。

  3. 「フェッチ」をクリックします。実際とプロキシの WSDL の両方を確認できます。また WSDL ポートをそのバインディング、実際とプロキシの SOAP エンドポイントと共に確認できます。次に例を示します。

  4. API の認証タイプをタイプドロップダウンリストから選択します。

  5. SLA プランを選択するか、プランを作成します。承認が得られるプランを作成するには、「承認」チェックボックスを選択します。

    承認を必要とする SLA プランを作成した場合、API サブスクライバーがその SLA プランで API を使用することを承認しない限り、そのサブスクライバーは API を使用できません。例えば、サブスクライバーに承認を必要とする GOLD プランを許可する場合、サブスクリプションリクエストを承認した場合にのみ、サブスクライバーは GOLD をサブスクライブできます。

    詳しくは、API に対するサブスクライバーの承認を参照してください。

  6. API を公開してサブスクライバーが利用できるようにするには、「パブリッシュ」をクリックします。

API を公開すると、サブスクライバーは API を試用したり、様々なアプリケーションで API を使用したりできます。

サブスクライバーでの API の試用方法については、SOAP API の試用を参照してください。

API の認証

API Manager で、API キーを使用して API およびアプリケーションを認証できます。API Manager は、API キーを生成し、API キーベースの認証を API に追加できるようにします。

API キーを使用した検証は、API の作成中に強制できるセキュリティのタイプです。アプリケーションは API キーを使用し、API Manager は API キーがリソースに対して承認された状態かどうかをチェックします。

API Manager は、3 種類の API 認証タイプを使用します。

  1. apiKey
  2. basicAuth
  3. OAuth2

認証タイプ

apiKey

API キーは、API を使用するための簡単な認証形式である不透明トークンです。 API キーを取得するには、サブスクライバーとしてアプリケーションを作成します。

API キーを使用して保護された API の使用

リクエストでは、次のいずれかの方法で API キーを API Manager に渡すことができます。

  • ヘッダー： api_key ヘッダーを使用して、API キーを API ランタイムに渡すことができます。
  • クエリパラメーター： api_key クエリパラメーターを使用して、API キーを渡すことができます。
  • フォームパラメーター： api_key フォームパラメーターを使用して、API キーを渡すことができます。

API キーを使用した認証について詳しくは、API キーを参照してください。

basicauth

基本認証は、API を使用するためのリクエストでユーザー名とパスワードを渡すことによってユーザーを認証する、最も簡単な認証方式です。API Manager では、基本認証スキームを使用して API を保護できます。

パブリッシャーは、認証に使用するユーザーストアを設定できます。また、API リソースがロールで設定されたスコープで保護されている場合、API Manager は API 呼び出しの使用時にロールも承認します。

基本認証では、ユーザーストアに従って認証を強制できます。

  1. ユーザーストアドロップダウンリストから、ユーザーストアを選択します。API 管理者がユーザーストアを作成します。
  2. スコープを作成します。スコープは、ユーザーストアで定義されたロールを定義します。スコープの名前を入力して、ロールを選択します。
  3. 新規作成したスコープを追加するには、「スコープを追加」をクリックします。

basicauth 認証について詳しくは、基本認証を参照してください。

OAuth2

OAuth2 は、パスワードを入力せずに、ユーザーの代わりにアプリケーションに認可を委任するための標準です。ユーザーパスワードの代わりに、（スコープを使用して）アクセスが制限され、有効期間が制限されたアクセストークンをアプリケーションに提供します。アプリケーションの種類によって、アクセストークンの取得方法が異なります。これは付与タイプと呼ばれます。

API Manager では、

  • アプリケーションは、作成した API のリソースへのアクセスの認証をリクエストします。
  • リクエストを承認すると、アプリケーションは認証を受けます。
  • アプリケーションは、ID の認証を提示した後、アクセストークンをリクエストします。
  • API は、アプリケーションにアクセストークンを発行します。

OAuth2 を設定するには、次の手順を実行します。

  1. Oauth タイプを USERSTORE または SAML から選択します。USERSTORE を選択する場合は、LDAP またはデータベース接続で定義されたユーザーストアを選択します。
  2. スコープを追加します。

サブスクライバーが、アプリケーションを作成します。リクエストを承認すると、サブスクライバーは、クライアント秘密キーを使用して、API リクエストを行います。

OAuth2 認証について詳しくは、OAuth2 を参照してください。

階層の API への追加

各リソースの使用に制限を強制して、複数の使用レベルを割り当てることができます。プランの API スロットルレベルを変更して、新しいプランを追加できます。API Manager のスロットルは、API Manager がリクエストできる最大頻度に制限を課します。

管理者は、2 つのアルゴリズムのうちの 1 つを選択することで API サービスレベル契約（SLA）を設定します。次に、レートとスロットルの制限を指定することで SLA を追加します。

パブリッシャーの場合、サブスクリプションプランを作成して、API にスロットル制限を割り当てることができます。既存の階層を変更するには：

  1. 管理者によって作成された任意のプランを選択します。

  2. プランの名前をクリックして、プロパティを変更します。

  3. API 頻度制限を変更します。秒、分または時間ごとのリクエスト数に対する API リクエスト頻度のみ制限できます。

  4. API スロットル制限を変更します。日、週または月ごとのリクエスト数に対する API スロットル頻度のみ制限できます。

  5. API リクエストの制限のタイプを選択します。

    次の 2 つのオプションがあります。

    • ハード：このオプションを選択すると、API リクエストの数は、スロットル制限を超えることはできなくなります。
    • ソフト：このオプションを選択すると、1％超えた API リクエスト制限を設定できます。例えば、「制限超過」を 90％に設定すると、API リクエストの数は、所定の制限の 90％を超えることができます。

  6. API リクエストプランを承認するには、「承認」チェックボックスを選択します。

  7. 新しい SLA プランを追加するには、「プランを追加」をクリックします。

頻度制限の API リソースへの追加

API がサブスクライブする SLA プラン用に、API のリソースに頻度制限を追加できます。API が頻度制限を超えると、サブスクライバーの応答ヘッダーに Status 429 が表示されます。また、サブスクライバー向けに試用の頻度制限が用意されています。API の試用に制限はありません。

頻度制限を API リソースに追加するには：

  1. SLA プランのリクエスト数を入力します。

  2. 情報を保存します。API リソースに新しい頻度制限が設定されます。

エンドポイントの指定

エンドポイントは、Web サービスのアドレスを定義します。REST および SOAP サービスの両方を公開して、API で使用できます。「エンドポイント」セクションで、次の詳細を入力します。

エンドポイントのタイプを選択します。

HTTP URL：このオプションを選択する場合、リソースを含むプライマリ URL または複数の URL を入力します。また、テストエンドポイント URL を入力して、サンドボックス環境で API をテストできます。

ロードバランサー：ロードバランサーを選択する場合、負荷分散アルゴリズムを選択します。負荷分散アルゴリズムには 2 種類あります。

  • ラウンドロビン：この手法では、負荷は、API エンドポイントにわたって順番に分散されます。すべてのエンドポイントは、同じ負荷を割り当てられ、同じパフォーマンスになります。「別のエンドポイントを追加」をクリックして、負荷を配分するエンドポイント URL を追加します。
  • 重みづけされたラウンドロビン：この手法では、負荷は、各エンドポイントに割り当てることのできる「加重値」要素に応じて、エンドポイントにわたってバランスが取られます。負荷は、割り当てられた重みを単位として分割されます。3 つのエンドポイントに割り当てられた重みがそれぞれ 100、50、50 の場合、最初のエンドポイントは、2 番目および 3 番目のエンドポイントの 2 倍のリクエストを処理します。

認証タイプ：エンドポイントに対する認証のタイプを選択します。次のタイプがあります。

  • クライアント認証：作成したキーストアとキーペアを選択します。
  • 共有シークレット：シークレットトークンを生成します。

チャンクエンコード：この チェックボックス は、リクエストデータをチャンク化されたエンコード（バイトストリーム）として API エンドポイントに送信する場合に選択します。無効にした場合、リクエストデータは、content-type ヘッダーに指定した文字セットでエンコードされた文字列として送信されます。デフォルトでは、エンコードにはオペレーティングシステムのエンコード設定が使用されます。リクエストデータで 2 バイト文字を送信する場合は、このオプションを有効にしてください。

API ポリシー

ColdFusion API Manager では、ポリシーを使用すると、設定を変更することで API の動作を変更できます。ポリシーは、API のリクエストや応答で順番に実行されるコマンドの集まり です 。

API Manager のポリシーには、次の 2 つの主なカテゴリがあります。

  • データ変換ポリシー
  • 脅威保護ポリシー
注意：
  1. API レベルで追加されたポリシーは、リソースレベルおよびサブリソースレベルで継承されます。
  2. 継承されたポリシーは削除できません。ポリシーは無効にのみできます。

コンテンツタイプ制限

API Manager では、入力タイプが「消費」または「生成」の場合に受理または拒否される MIME タイプのリストを指定できます。コンテンツタイプをリクエストレベルで検証すると、JSON クロスサイトリクエストフォージェリ（CSRF）などの脆弱性を軽減するのに役立ちます。

API Manager のコンテンツタイプ制限では、コンテンツタイプが、指定された Content-Type ヘッダーまたは Accept ヘッダーと一致するかどうかを検証します。

また、Content-Type ヘッダーまたは Accept ヘッダーがないリクエストを拒否することもできます。

ポリシー名

コンテンツタイプ制限ポリシーの名前。

許可するコンテンツタイプ

許可するコンテンツ タイプ。

拒否するコンテンツタイプ

制限するコンテンツタイプ。

API 操作のコンテンツタイプを遵守

グローバルに作成されたポリシーをオーバーライドし、API レベルのポリシーを使用できるようになります。例えば、「application/postscript」コンテンツタイプがグローバルポリシーレベルで拒否されていて、API レベルで許可されている場合、API レベルでの設定が優先されます。

ペイロードを検査してコンテンツタイプを検出

ヘッダーを検査してコンテンツタイプを判断します。

XML 脅威保護

XML アプリケーションに対する悪意のある攻撃では、通常、大量のペイロードが繰り返し使用されたり、XPath/XSLT または SQL インジェクションが関与したりします。XML 脅威保護ポリシーを使用すると、ノードの深さの上限やテキストノードの長さの上限など、XML コード内の情報のサイズを制限して、悪意のある攻撃を阻止することができます。

ポリシー名

XML 脅威保護ポリシーの名前。

DOCTYPE 宣言を許可

この チェックボックス を選択すると、XML 脅威保護のパラメーターを設定できます。

外部 DTD を読み込む

DOCTYPE 宣言で外部 DTD を読み込む場合は、このチェックボックスを選択します。次に例を示します。

<?xml version="1.0" standalone="no" ?>

<!DOCTYPE document SYSTEM "//path//to//DTD">

エンティティ拡張制限

許容されるエンティティ拡張回数の上限を示します。つまり、これは、XML パーサーが 1 つのドキュメントで許可するエンティティ置換の回数の上限です。デフォルト値は 64,000 です。

XML エンティティ拡張（XML Entity Expansion、XXE）攻撃を防ぐには、XML エンティティ拡張の限度を設定します。XML エンティティ拡張攻撃では、XML DTD でエンティティを作成してドキュメント全体で使用できる機能を悪用します。ドキュメントの最上位で一連のカスタムエンティティを繰り返し定義することで、攻撃者は、エンティティを完全に解決しようとするパーサーに、これらの再帰定義をほとんど無限に反復処理させて、大きな負荷を与えることができます。

悪意のある XML メッセージを使用して、使用可能なサーバーリソースを使い果たす再帰的なエンティティ拡張（やその他の反復処理）を強制的に実行させるのです。この種の攻撃のよくある例は、「many laughs」攻撃です（「billion laughs」攻撃と呼ばれることもあります）。

次に例を示します。

<?xml version="1.0"?>

<!DOCTYPE lolz [

 <!ENTITY lol "lol">

 <!ELEMENT lolz (#PCDATA)>

<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">

 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">

 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">

 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">

 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">

<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">

 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">

 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">

 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">

]>

<lolz>&lol9;</lolz>

汎用エンティティのサイズの上限

あらゆるエンティティの最大サイズ。上限をできるだけ小さい数に設定することで、不正な形式の XML ファイルをすばやく検出できるようにすることをお勧めします。

パラメーターエンティティのサイズの上限

複数のパラメーターエンティティをネストした結果を含む、あらゆるパラメーターエンティティの最大サイズ。

要素の深度の上限

XML 要素の ルートからの 深さの 上限 。例えば、次の XML 要素の場合を見てみます。

 

<company>

        <staff>

                <firstname>John</firstname>

                <lastname>Doe</lastname>

                <salary>100000</salary>

                <age>29</age>

        <staff>

</company>

 

最大の深さは 3 です。指定された上限が 3 より小さい場合は、XML 保護ポリシーが強制されます。

Max Attributes Per Element（要素あたりの属性数の上限）

要素に含めることができる属性の最大数。これにより、XML Attribute Blowup 攻撃を防ぐことができます。例えば、次の XML 要素には最大 1000 個の属性があります。

 

<?xml version="1.0"?>

<foo a1="" a2="" ... a1000=""/>

属性名の最大サイズ

要素の属性名で使用可能な文字数の上限。

許可されているプロトコル

使用可能なプロトコルスキームのリスト。

 

許可されている XXE ドメイン

API Manager が XSD スキーマ定義の取得先として許可しているドメイン名／IP アドレスのホワイトリスト。次に例を示します。

 

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

JSON 構造制限ポリシー

JSON をサポートしている API は攻撃に対して脆弱です。JSON 攻撃では、通常、JSON パーサーに過重な負荷をかける構造を使用して、DoS 攻撃の連鎖を開始します。JSON 脅威保護ポリシーでは、JSON ドキュメントの構造を検証し、その構造に対して制約を強制します。

受信した JSON ドキュメントの構造が指定の制約を超えると、API Manager がその JSON リクエストを拒否し、ポリシーのそれ以上の処理を制限します。

ネストの最大深さ

JSON ドキュメント内にネストできるコンテナの最大ネストレベルを指定します。例えば、次の JSON ドキュメントでは一方の JSON オブジェクトがもう一方の JSON オブジェクトに含まれており、ネストレベルは 2 となっています。

{"label":{"label1":"value"}}

例 2：次の JSON ドキュメントでは、address のコンテナの深さは 2 です。

{

    "message" : "Hello World",

    "names" : ["John","Paul","George"],

    "address" : {

                         "street" : "Bleecker street",

                         "housenumber" : 50

                }

} 

オブジェクトごとの最大エントリ数

単一オブジェクト内のエントリ数の上限。上記の例 2 では、エントリは message、names および address で、最大数は 3 です。

配列ごとの最大エントリ数

配列内の要素の最大数。上記の例 2 では、JSON ドキュメント内の配列ごとの最大エントリ数は 3 です。長さが 4 の配列があると、この JSON ドキュメント全体が拒否されます。

キーの最大長

オブジェクト内のプロパティ名の文字列の最大長を指定します。上記の例 2 で、キー housenumber の長さは 11 です。キーの最大長が 11 より小さい場合、この JSON ドキュメントは拒否されます。

文字列値の最大長

文字列に許される長さの上限を指定します。上記の例 2 では、最長の文字列は Bleecker street です。文字列の最大長が 15 より小さい場合、この JSON ドキュメントは拒否されます。

IP アクセス制御による保護

このポリシーでは、IP アドレスに基づいて API へのアクセスを制限したり許可したりすることができます。IP アドレスのリストのほか、ワイルドカードベースのアドレス、正規表現に基づくアドレスまたは IP アドレスの範囲を追加することができます。IP アクセスポリシーでは、IPv4 と IPV6 の両方のアドレスをサポートしています。

ホワイトリスト IP アドレス

API へのアクセスが許可された IP アドレスのリスト。

ブラックリスト IP アドレス

API へのアクセスが拒否された IP アドレスのリスト。

HTTP メッセージ制限

場合によっては、メッセージの内容だけでなくメッセージの外部特性に基づいて、メッセージをフィルタリングする必要があることがあります。リクエスト／応答のメッセージ／ペイロードの指定サイズを超えるメッセージを拒否するように API Manager を設定することができます。

最大パラメーター数

リクエストで使用できるクエリパラメーターやフォームパラメーターの最大数。指定された値を超えたリクエストをクライアントが送信した場合は、接続が拒否されます。この制限は、ハッシュベースのサービス拒否攻撃を防ぐのに必要です。デフォルト値は 1000 です。

最大ペイロードサイズ（バイト）

リクエストのペイロードに割り当てられるサイズの上限。エンティティのサイズがこの上限より大きい場合は、リクエストの読み取り時に例外が発生します。

最大ヘッダー数

リクエストに含めることができるヘッダーの最大数。この上限を超えるリクエストをクライアントが送信した場合は、API Manager が接続を終了させます。この制限は、ハッシュベースの DoS（サービス拒否）攻撃を防ぐのに必要です。

最大ヘッダーサイズ

HTTP  ヘッダーブ ロックの最大サイズ（バイト単位）

XML から JSON への変換

API では、通常、リソースの複数の表現をサポートしています。例えば、ColdFusion API では、リクエストと応答のペイロードについて、XML 表現と JSON 表現の両方をサポートしています。

しかし、複数の表現をサポートしていない API もあります。例えば、API で XML ペイロードのみサポートしている場合がありますが、Web アプリケーションでは JSON 形式の応答が必要になる可能性があります。

このような場合、データ変換メカニズムが必要になります。ColdFusion API Manager では、アプリケーションで解釈できる JSON 形式または XML 形式にリクエストを変換します。

ポリシー名

XML から JSON への変換ポリシーの名前。

 

Json 属性の接頭辞

JSON の属性の接頭辞に使用する文字列。

例えば、<name id="John"/> という XML の場合、変換後の JSON は次のようになります。

{

   "apim_attrib_id" ":"John"

}

デフォルトは apim_attrib_id

Text Element Key（テキスト要素キー）

JSON 出力のテキストノードの名前を表す文字列。例えば、テキスト要素キーがデフォルト（$text）に設定されている場合は、<title xml:lang="en-us">The Catcher In The Rye</title> という XML は次の JSON に変換されます。

{

    "apim_attrib_xml:lang":"en-us",

    "apim_key":"The Catcher In The Rye"

}

デフォルトは apim_key

Start Element（開始要素）

JSON 出力のルート。次に例を示します。

    <name>Joe</name>

    <age>22</age>

開始要素が「person」の場合は、出力は次のようになります。

{

    "person": {

        "name": "Joe",

        "age": "22"

    }

}

デフォルトは apim_root

配列要素

JSON ドキュメント内の配列として表現する必要がある値。例えば、次のような XML があるとします。

<locations>

    <location>San Francisco</location>

    <location>London</location>

    <location>Tokyo</location>

</locations>

「配列要素」フィールドに "location" を入力し、「自動配列」オプションが有効になっている場合、シリアル化された JSON ドキュメントは次のようになります。

{

    "locations": {

         "location": ["San Francisco","London","Tokyo"]

     }

}

次のように、XML に空ノードが含まれている場合は、

<locations>

   <location/>

</locations>

JSON 出力では、空の配列が生成されます。例えば、次のようになります。

{

    "locations": {

         "location": []

     }

}

 

自動配列

このチェックボックスを選択すると、XML ドキュメントの構造に基づいて配列が自動的に作成されます。次のような XML ドキュメントがあるとします。

<locations>

    <location>San Francisco</location>

    <location>London</location>

    <location>Tokyo</location>

</locations>

例えば、このチェックボックスをオンにしない場合、JSON 出力は次のようになります。

{

   "locations" : {

        "location":"San Francisco",

        "location":"London",

        "location":"Tokyo"

    }

}

このチェックボックスをオンにすると、出力は次のようになります。

{

    "locations": {

         "location": ["San Francisco","London","Tokyo"]

     }

}

 

Interpret Datatypes（データ型を解釈）

データ型が数値およびブール値であるとして自動決定を試みるように指定します。これが有効な場合、JSON 出力の値は、XML で指定されたデータ型になります。無効な場合は、JSON の値はすべて文字列値になります。例えば、次の XML では、

<person>

   <name>Joe</name>

   <age>22</age>

   <membership>true</membership>

</person>

「Interpret Datatypes（データ型を解釈）」を有効にした場合、出力される JSON は次のようになります。

{

    "person": {

        "name": "Joe",

        "age": 22,

        "membership": true

    }

}

「Interpret Datatypes（データ型を解釈）」を無効にした場合、出力される JSON は次のようになります。

{

    "person": {

        "name": "Joe",

        "age": "22",

        "membership": "true"

    }

}

デフォルトは有効

Interpret Processing Instructions（処理命令を解釈）

例で使用する処理命令（<?multiple_pi location?>）を指定します。例えば、XML に定義されている PI <?xml-stylesheet href="mystyle.css" type="text/css"?> が変換時に使用されます。

デフォルトは無効
注意：

XML から JSON への変換では、引用符は &quot;. としてエンコードされます。次に例を示します。

<locations id="1">

    <location>

        <name>Chicago</name>

        <description>Jason's in Chicago, also known as "Windy City".</description>          

      </location>

</locations>

変換結果の JSON は次のようになります。

{

  "locations": {

    "location": {

        "name": "Chicago",

        "description": "Jason's in Chicago, also known as \"Windy City\""

      }

    "@id": 1

  }

}

JSON から XML への変換

ポリシー名

JSON から XML への変換ポリシーの名前。

 

Root Element（ルート要素）

結果の XML にルートノードを追加します。例えば、「Root Element（ルート要素）」が student の場合、

{

   "name":"Jason"

}

XML 出力は次のようになります。

<student>

  <name>Jason</name>

</student>

デフォルトは apim_root

Normalize JSON Keys（JSON キーを正規化）

JSON ドキュメントで使用されているオブジェクト名が XML ノードでは有効でない場合があります。例えば、JSON ではスペースはオブジェクト名として有効ですが、XML ではスペースは無効です。このチェックボックスを選択すると、変換後の XML では有効な要素名が使用されます。スペースと @ や $ などの特殊文字は無効な文字です。

デフォルトは有効

Create Processing Instructions（処理命令を作成）

JSON 配列要素が検出されると、XML 処理命令が作成されます。

デフォルトは無効
注意：

例えば、次のように JSON ペイロードに引用符が含まれている場合を考えてみます。

{

  "locations": {

    "location": {

        "name": "Chicago",

        "description": "Jason's in Chicago, also known as \"Windy City\""

      }

    "@id": 1

  }

}

変換結果の XML は次のようになります。

<DocumentRoot>

    <locations id="1">

        <location>

            <name>Chicago</name>

            <description>Jason's in Chicago, also known as the &quot;Windy City&quot</description>

        </location>

    </locations>

</DocumentRoot>

ポリシーのエラーコード

ポリシー

エラーコード

XML 脅威からの保護

403（設定されている限度をいずれかのフィールドが超えた場合）

HTTP メッセージの制限

  • 413（合計ペイロードのサイズに設定されている限度を超えた場合）
  • 431（次のものに設定されている限度を超えた場合）
    • パラメーターの数
    • ヘッダーの数
    • ヘッダーのサイズ

IP アクセス制御

403（受信した IP アドレス xxx.xxx.xxx.xxx が API にアクセスできない場合）

コンテンツタイプの制限

403（受信した コンテンツタイプ が API にアクセスできない場合）

  • JSON 構造体の制限

  • 403 （ 行 y、列 z に定義されているエントリ x の数についての限度を JSON 配列が超えている場合）
  • 403（行 y、列 z に定義されているエントリ x の数についての限度を JSON オブジェクトが超えている場合）
  • 403（行 y、列 z に定義されている長さの上限 x を JSON 値が超えている場合）
  • 403（行 y、列 z に定義されている長さの上限 x を JSON オブジェクトのキー名が超えている場合）
  • 403（行 y、列 z に定義されている限度 x を JSON 構造体のネストの深さが超えている場合）
  • 400（行 x、列 y の JSON 解析でエラーが発生した場合）

キーストア

キーストアは、SSL 暗号化のインスタンスに使用されるセキュリティ証明書（認証証明書か公開キー証明書のどちらか）および対応する秘密キーのリポジトリです。

次のいずれかの方法でキーストアを使用できます。

  • キ ーストア には、SSL サーバーが SSL クライアントに対して自分自身を認証するのに使用する秘密キーと証明書が格納されています。慣例的に、そのようなファイルを キーストア と呼びます。
  • 信頼ストア として使用する場合、このファイルには、信頼できる SSL サーバーの証明書、または、サーバーを識別するための信頼できる認証機関の証明書が格納されています。秘密キーは、 信頼ストア にはありません。

キーストアを作成するには：

キーストアをインポートするには：

1.       「キーストアを作成」をクリックします。

2.       キーストアの名前とパスワードを設定します。

3.       「作成」をクリックします。

4.       「証明書をインポート」をクリックします。

5.       証明書のエイリアスを入力し、 keytool コマンドラインまたは GUI を使用して作成した証明書ファイルを選択します。

6.       「証明書をインポート」をクリックします。

1.       「キーストアをインポート」をクリックします。

2.       次の詳細を入力します。

a.       キーストアの名前。

b.      キーストアのパスワード。

c.       既に作成してある証明書を選択します。

d.      キーストアのタイプ（JKS または PKCS）を選択します。

e.      （オプション）証明書のエイリアスを入力します。

3.       「作成」をクリックします。

API のビジネスの詳細の追加

「ビジネス情報」セクションに、ビジネスの詳細を入力します。

API に対するサブスクライバーの承認

API に対するサブスクリプションを承認したり、拒否したりできます。「サブスクリプション」をクリックして、すべてのサブスクリプションリクエストのリストを表示します。

サブスクライバーの削除

サブスクライブ済みユーザーは、サブスクライブ済みユーザーページで削除できます。「アクション」の下のゴミ箱ボタンをクリックすると、サブスクライバーが削除されます。

サブスクライブ済みユーザーの表示

すべてのサブスクライブ済みユーザーのリストを表示します。各ユーザーに対して、次を確認できます。

  • ユーザー名
  • 姓名
  • 電子メール ID
  • 電話番号
  • アクション

通知の表示

パブリッシャーポータルでは、次のような状況における通知をチェックできます。

  • API サブスクリプションの承認をリクエストする
  • 承認済み API サブスクリプション
  • API の終了または非推奨
  • API エンドポイントのエラー
  • SLA が制限に達する

サブスクライバーがアプリケーションをサブスクライブすると、対応する通知を受け取ります。

「通知」をクリックすると、すべてのサブスクライバーメッセージを表示して、適切なアクションを取ることができます。

API の公開

「パブリッシュ」をクリックして、API を公開します。

分析ダッシュボードの表示

パブリッシャー向けの分析ダッシュボードには、API 指標、成功および失敗したリクエスト、API リクエスト数などのビジュアライゼーションが含まれています。「分析」をクリックして、パブリッシャー分析ページを起動します。

パブリッシャーポータルには、5 種類のダッシュボードがあります。

  • ホーム
  • API
  • API とバージョン
  • 開発者
  • エラー

ホーム：ホームダッシュボードパネルでは、次のビジュアライゼーションを表示できます。

1

合計リクエスト数とエラーのあるリクエスト数を含む、ある期間内の API リクエスト数。

2

API の成功とエラーを表すドーナツグラフ。

3

API の平均応答時間、API リクエスト数などの指標データ。

4

API の平均応答時間（ミリ秒単位）。

5

キャッシュのヒットまたは失敗。

6

成功および失敗した API リクエストの折れ線グラフ。

API：API ダッシュボードパネルでは、次のビジュアライゼーションを表示できます。

1

上位 5 つの API のリクエスト数とバージョン。

2

上位 5 つのアプリケーションによる、API リクエスト数のドーナツグラフ。

3

API のバージョンを比較した、API リクエストの成功と失敗の割合を示すドーナツグラフ。

4

API の平均応答時間を示す棒グラフ。

5

上位 3 つの API による、リクエスト数の折れ線グラフ。

6

API リクエスト数。

7

API 指標データ（例：平均応答時間）のドーナツグラフ。

8

キャッシュのヒットまたは失敗の表示。

API とバージョン：API とバージョンダッシュボードパネルでは、次のビジュアライゼーションを表示できます。

1

上位 5 つの API のリクエスト数とバージョン。

2

上位 5 つの API の平均応答時間を示す棒グラフ。

3

成功および失敗した API リクエストの割合を示すドーナツグラフ。

4

異なる API バージョンを比較した、上位 3 つの API リクエストを示す折れ線グラフ。

5

API リクエスト数と API の平均応答時間。

6

上位 5 つのアプリケーションによる、API リクエスト数。

7

API データ使用量（MB 単位）。

開発者：開発者ダッシュボードパネルでは、次のビジュアライゼーションを表示できます。

1

上位 5 つのプラン使用量を示す円グラフ。

2

メソッドタイプに対する API リクエスト数。

3

API のサブスクライバー数。

4

サブスクライバーに対するリクエスト数の円グラフ。

5

上位 5 つの API に対するリクエスト数。

6

上位 3 人のサブスクライバーからのリクエストの折れ線グラフ。

7

上位 5 つのアプリケーションに対するリクエスト数の円グラフ。

8

上位 3 つの SLA プランからのリクエストの折れ線グラフ。

エラー：エラーダッシュボードパネルでは、次のビジュアライゼーションを表示できます。

1

上位 5 つの API からのエラー数。

2

上位 5 つのアプリケーションからのエラー数。

3

すべてのステータスコードからのエラー数のドーナツグラフ。

4

上位 5 つのエラータイプを示す円グラフ。

5

上位 5 つのエラータイプに対するリクエストを示す折れ線グラフ。

6

すべてのステータスコードに対するリクエストの折れ線グラフ。

7

最大エラー数による上位 10 リソースのリスト。

期間によるデータのフィルタリング

分析ページでは、期間に応じて結果をフィルタリングできます。次の 3 つのオプションがあります。

  1. Quick（クイック）
  2. Relative（相対）
  3. Absolute（絶対）
期間によってデータをフィルタリングするには：

  1. 次に示すように、時間のフィルターをクリックします。

  2. 次に示すように、リストから期間を選択します。

    「Today（今日）」を選択すると、過去 24 時間のすべての API の分析を確認できます。

  3. 「Relative（相対）」をクリックします。指定した日時から現在の日時までのデータをフィルタリングできます。

  4. 「Absolute（絶対）」をクリックします。日付に応じて結果をフィルタリングできます。

ビジュアライゼーションの作成

カスタムのビジュアライゼーションを作成して、将来の分析のために保存することができます。次の手順に従って、ビジュアライゼーションを作成します。

  1. ビジュアライゼーションを作成するには、「Visualize （ビジュアライズ）」タブをクリックします。

  2. API 情報からの面グラフ、データテーブル、円グラフなどの形式でビジュアライゼーションを作成できます。例として、API 分析から円グラフを作成します。リストから「Pie chart（円グラフ）」をクリックします。

  3. 次から選択します。

  4. 新規検索からビジュアライゼーションを作成します。「From a new search（新規検索から）」を選択します。パブリッシャーによる新しい API の数を表す円グラフを確認できます。

  5. 次から円グラフのタイプを選択します。

    • Split Slices（スライスに分割）
    • Split Chart（チャートに分割）

  6. 「Split Slices（スライスに分割）」を選択して、」Aggregation（集計）ドロップダウンリストから「Date Histogram（日付ヒストグラム）」を選択します。

  7. 「Apply（適用）」をクリックします。パラメーター（この場合は、タイムスタンプ）に従って分割円グラフが表示されます。

フィールドベースのフィルタリング

API の使用状況を把握しやすくするために、ダッシュボードをフィールドに従ってフィルタリングすることができます。api、version、resourcePath などのフィールドを使用できます。フィルターを適用すると、それに応じてダッシュボードが変化し、結果がグラフィカルに表示されます。

フィールドに従ってダッシュボードの情報をフィルタリングするには：

  1. ダッシュボードの種類を次の中から選択してクリックします。

    • ホーム
    • API
    • API およびバージョン
    • 開発者
    • エラー

  2. 任意のダッシュボードを選択し、そのグラフの上にマウスポインターを置くと、フィールドとそれらの値が表示されます。次のスナップショットには、上位 5 つの API のリクエスト数を示すダッシュボードのフィールド値が表示されています。

    特定の API のすべてのフィールド値とその API の呼び出し回数を示すリストが表示されます。

  3. グラフをクリックします。フィールドレベルのフィルターがダッシュボードの上部に表示されます。

  4. フィルターを選択（または選択を解除）し、「Apply Now（今すぐ適用）」をクリックします。すべてのダッシュボードがフィルターに従って変更され、API を詳細に表示することができます。次のスナップショットは、API usweather のフィールド値を表しています。

 Adobe

ヘルプをすばやく簡単に入手

新規ユーザーの場合

クイックリンク

すべてのプランを表示 プランを管理
クイックリンクを表示する
クイックリンクを非表示にする
Adobe MAX 2025

Adobe MAX Japan
クリエイターの祭典

2025 年 2 月 13 日
東京ビッグサイト

今すぐ登録

リーガルノーティス    |    プライバシーポリシー