REST API消費パターン
「RESTアダプタ」を使用して、次の共通パターンを実装し、REST APIを使用できます。
APIキーで保護されたREST APIを使用するように「RESTアダプタ」を構成
このセクションでは、APIキー・ベース認証セキュリティ・ポリシーの概要を説明します。 このポリシーを使用すると、APIへの安全なアクセスを提供できます。 リソース所有者は、所与のクライアント・アプリケーションのAPIキーを必要な権限で生成し、生成されたAPIキーを共有します。 クライアント・アプリケーションは、保護されたリソースへのアクセス・リクエストとともにAPIキーを渡す必要があります。
次のステップは、APIのキー・ベース認証フローの一部として実行されます。
| ステップ | 説明 |
|---|---|
| 1 | リソース所有者は、指定されたクライアント・アプリケーションのAPIキーを認証して生成します。 |
| 2 | リソース所有者は、生成されたAPIキーをクライアント・アプリケーションと共有します。 |
| 3 | クライアント・アプリケーションは、APIキーを使用してリソースをリクエストします。 |
「RESTアダプタ」の接続ページで、「APIキー・ベースの認証」を選択します。
「
図oic3_api_key_based_auth.pngの説明」
「APIキーの使用」フィールドには、リソースへのアクセス・リクエストとともにAPIキーがどのように渡されるかを指定します。 この情報は、このAPIキーをエンドポイントに渡す方法を管理するため、この情報を慎重に入力してください。 詳細は「接続セキュリティの構成」を参照してください。
実行時に、リクエストを送信する間、APIキーが自動的にエンドポイントに渡されます。
「接続セキュリティの構成」を参照してください。
ドキュメントで説明されているメタデータのない外部REST APIを使用するためのRESTアダプタの構成
Oracle Integrationは、サービス記述を公開していないREST APIと統合できます。 次の例は、これらのREST APIと統合する方法を示しています。 この例では、英国の炭素強度データを提供する公開されているAPIを使用しています。
ノート:
「RESTアダプタ」は、メタデータ・カタログを使用して説明されているREST APIの使用をサポートします。 ただし、標準としてのメタデータ・カタログはアクティブに保守されていないため、メタデータ・カタログ定義を使用しないことをお薦めします。 多くのアプリケーションは、すでにリソース・モデルをOpenAPI仕様に移動しています。これは、RESTful APIを記述するための優先メタデータの説明です。 メタデータ・カタログが唯一のメタデータ定義である場合、アダプタ・エンドポイント構成ウィザードの一部として提供されているリクエスト・ビルダーを使用して、ターゲットREST APIを直接消費するオプションがあります。APIはhttps://carbon-intensity.github.io/api-definitions/#intensityで説明されています。 この例では、炭素強度データを取得するために統合をモデル化しています。 APIは保護されていないため、セキュリティ構成は不要です。
CURLコマンドを使用して起動することもできます:curl -X GET https://api.carbonintensity.org.uk/intensity/date -H 'Accept: application/json'{"data":[ {"from": "2018-01-20T12:00Z",
"to": "2018-01-20T12:30Z",
"intensity": {
"forecast": 266,
"actual": 263,
"index": "moderate"
}
}]
}
-
「接続タイプ」フィールドで「REST APIのベースURL」を選択し、「接続URL」フィールドにサービスのベースURLを指定して接続を構成します。 「起動接続の接続プロパティの構成」を参照してください。
接続をテストして保存します。 一般に、REST APIのベースURLは、REST APIのリソース・ルートである必要があります。 この例では、「接続URL」フィールドは
https://api.carbonintensity.org.ukとして構成されています。次のステップでは、アダプタ・エンドポイント構成ウィザードで相対RESTリソースを構成する方法について説明します。
-
「RESTアダプタ」を起動接続として構成します。 Oracle Integrationは、接続構成中に構成されたベースURLに相対リソースURIを追加して、ターゲット・エンドポイントURLを決定します。
-
/intensity/dateの相対リソースURIを指定し、使用するHTTP動詞を選択します(この例ではGET)。この例では、リクエスト・ペイロードは必要ありません。 したがって、対応するオプションは選択されていません。 問合せとテンプレートのパラメータについても同様です。 しかしながら、レスポンスが期待されるので、レスポンスに対応するオプションが選択されます。 アダプタ・エンドポイント構成ウィザードは、このページで選択したオプションに基づいて表示する次のページを決定します。
「
図oic3_receive_response.pngの説明」
リクエスト・ペイロード、リクエスト・パラメータ(問合せとテンプレート・パラメータ)、およびリクエスト・ヘッダーに対応するオプションが選択されていないため、対応するページはスキップされます。
-
必要なペイロード形式を選択し、ペイロードを表すJSON、XML、またはスキーマのサンプルを提供します。
<<<inline>>>オプションを使用してJSONサンプルを提供することもできます。
「図rest_adapter_json_spl.pngの説明」 -
残りのAdapter Endpoint Configuration Wizardを完了します。
-
マッピングを完了します。
カスタムHTTPヘッダー・プロパティを予想するREST APIを使用するように「RESTアダプタ」を構成する
「RESTアダプタ」は、外部HTTPサービスを簡単かつ構成可能に使用できます。 リクエストの一部として送信する必要があるHTTP動詞、リソースURI、問合せおよびテンプレート・パラメータ、HTTPヘッダー、フォーム・パラメータ、本文、および添付ファイルを構成できます。
「図http_request.pngの説明」
HTTPヘッダーは、クライアントとサービスがリクエストまたはレスポンスと共に追加の情報を交換できるようにします。 Internet Assigned Numbers Authority (IANA)は、あらかじめ定義された理由のために一般的に使用される標準または永続的なHTTPリクエスト・ヘッダーのレジストリを保持します。 標準ヘッダーとともに、サービスは付加的な情報を交換するための独自のヘッダーを定義することもできます。
カスタムHTTPリクエスト・ヘッダーを必要とするRESTサービスを起動するには、以下のステップに従います。
-
ターゲット・サービスが消費するRESTアダプタ起動接続を使用して接続を作成します。
-
接続を統合キャンバスにドラッグします。
-
「基本情報」ページで、HTTP動詞と相対リクエストURIを入力します。
-
「リクエスト・ヘッダーを構成」セクションで「カスタム」を選択します。
RESTアダプタには、カスタム・リクエスト・ヘッダーを構成するためのページが表示されます。
-
独自のヘッダー名を定義し、ヘッダーの簡単な説明を入力します。
完了すると、RESTアダプタは、上記のカスタム・ヘッダーをアダプタ・リクエスト・ペイロードの一部として公開します。
-
割り当てアクションまたはマッパーを使用して、このヘッダーに値を割り当てます。 割り当てられた値は、実行時にカスタムHTTPヘッダーとしてターゲット・サービスに送信されます。