はじめに

以前の記事で、IBM API ConnectのAPI定義と疎通確認について解説しました。今回は、その続きとして実際にバックエンドAPIと連携する方法を解説します。

具体的には、weatherapi.comと連携し、リクエストに応じて天気情報を返すAPIを定義します。基本的な流れは前回と一緒なので、今回は異なる部分を中心に見ていきましょう。

Weather Apiについて

サービス概要

ドバイを拠点に、現在・過去・未来予報などさまざまな気象情報を提供しているサービスです。データ取得用のAPIも公開しています。執筆時点では、有料プランのほかに無料プランも提供されています。

利用にはサインアップが必要ですが、特に難しい操作はありません。

curlによるAPIコール

今回は多数ある機能の中から、「指定した過去の日付・場所の天気情報を取得するAPI」を使ってみます。q（地名）、dt（日付）、hour（時刻・任意）、key（APIキー）をパラメータとして渡します。

request （25/9/11 15時の東京の天気は？）

curl -X GET 'https://api.weatherapi.com/v1/history.json?q=tokyo&dt=2025-09-11&hour=15&key=<YOUR API KEY>' -H 'accept: application/json'

response（結果一部省略）

{
	"location": {
		"name": "Tokyo",
		"region": "Tokyo",
		"country": "Japan",
		"lat": 35.6895,
		"lon": 139.6917,
    },
	"forecast": {
		"forecastday": [
			{
				"date": "2025-09-11",
				"day": {
					"condition": {
						"text": "Light rain shower",
					},
				},
				"hour": [
					{
						"time": "2025-09-11 15:00",
                        "condition": {
							"text": "Patchy rain possible",
						},
						"wind_kph": 15.1,
						"humidity": 68,
						"cloud": 86,
					}
				]
			}
		]
	}
}

今回作成するAPIの仕様

想定する接続URLはhttps://（ホスト）/(プロバイダーID)/sandbox/api2/weatherHistoryです。このURLにアクセスすると、バックエンドのWeatherAPIが呼び出されるようなAPIを定義していきます。

このAPIでは、以下の要件を設定します。

ユーザーがアクセスするパスを変更する
WeatherAPIのAPIキーをユーザーに公開しない
ユーザーから地名と日時を受け取り、結果はconditionのみを抽出して返却する

ここでは要件を実現するための手順の一例を記載しますが、API Connectにはさまざまな機能が提供されているため、他にも複数の実装方法が考えられます。実際に作成する際は、保守性や拡張性を考慮した最適な実装を検討してください。

OpenAPI定義をもとにAPIを追加する

バックエンドサービスのOpenAPI定義があると、API Connect上での定義作業が効率化できます。今回は、生成AIで作成したWeatherAPIのOpenAPI定義を使用します。

weather.yaml

openapi: 3.0.0
info:
  title: WeatherAPI.com
  description: WeatherAPI の主要エンドポイントを網羅した OpenAPI 仕様
  version: 1.0.0
servers:
  - url: https://api.weatherapi.com/v1
paths:
  /history.json:
    get:
      summary: 過去の天気情報を取得
      parameters:
        - name: key
          in: query
          required: true
          schema: { type: string }
        - name: q
          in: query
          required: true
          schema: { type: string }
        - name: dt
          in: query
          required: true
          description: 日付（YYYY-MM-DD）
          schema: { type: string, format: date }
        - name: hour
          in: query
          required: false
          description: 24時間表記. For example 5 pm should be hour=17, 6 am as hour=6
          schema: { type: integer }
      responses:
        '200':
          description: 成功
          content:
            application/json:
              schema: { type: object }

API ManagerでAPIを追加します。「OpenAPI3.0」の「既存のOpenAPIサービスから」を選択し、OpenAPI定義を記載したYAMLファイルをアップロードします。

詳細設定はデフォルトのままで、「クライアントIDを使用した保護」をOFFにします。これで追加作業は完了です。

パスを編集する

ユーザーからのアクセスパスを要件に合わせて変更します。

サーバーURLをapi2に変更します。

「/history.json」で設定されているパスを、「/weatherHistory」に変更します。「更新」ボタンをクリックすると編集可能になるため、書き換えます。

ゲートウェイのプロパティー（target-url）を、https://api.weatherapi.com/v1/ に変更します。このURLは、バックエンドへリクエストを転送する際に利用されます。

また、API実行時に適用されるルールや処理を定義するポリシー設定も行います。ここでは、バックエンドへの処理を転送するinvokeポリシーを定義します。

初期状態でinvokeポリシーが配置されていますが、正しく動作しない可能性があるため、一度削除して再度追加してください。

invokeポリシーでは、次の2点を変更します。
「URL」は、バックエンド側を呼び出すURLを指定します。パラメータなどを使用した文字置換で動的にURLを構成することができます。

$(target-url)/history.json

まず先ほど定義したtarget-urlをベースに、今回利用したAPIであるhistory.jsonのパスを連結します。

「Backend Type」は今回の機能にあわせて「JSON」を選択します。

「parameter-control」は、ユーザーリクエストのパラメータをバックエンドに引き継ぐ方法を指定する項目です。今回はBlocklistを選択し、パラメータは何も指定しません。これにより、すべてのパラメータを引き継ぐ設定になります。

変更内容を保存し、APIの公開を行います。
ここまでの定義で、変更されたパスにリクエストしてWeatherApiの機能が呼びだせます。

request

curl -X GET 'https://<ホスト>/<プロバイダーID>/sandbox/api2/weatherHistory?q=tokyo&dt=2025-09-11&hour=15&key=<YOUR API KEY>' -H 'accept: application/json'

APIキーを隠ぺいする

次に、APIキーをパラメータに含めなくても呼び出せるように設定します。

まず、外部向け定義から必須パラメータであるkeyを削除します。

次に、ゲートウェイタブで変数として使用するapikeyを追加し、WeatherAPIのキー文字列を設定します。

そして、invokeポリシーを再度修正します。

「parameter-control」: Allowlistを指定します。今回は許可する項目を指定しないため、「ユーザーからのパラメータは一切引き継がない」設定になります。
「URL」: 次のように指定します。これにより、ユーザーからのパラメータを明示的に追加するとともに、先ほど設定したapikeyがクエリパラメータとして追加されます。

$(target-url)/history.json?$(request.querystring)&key=$(apikey)

ここまでの変更を保存・公開すると、APIキーなしで呼び出せるようになります。

request

curl -X GET 'https://<ホスト>/<プロバイダーID>/sandbox/api2/weatherHistory?q=tokyo&dt=2025-09-11&hour=15' -H 'accept: application/json'

特定項目のみをレスポンスする

WeatherAPIのレスポンスをそのままユーザーに返却していますが、一部項目のみ必要というケースがあります。ここでは、指定時刻の天気（上の例では15時の"Patchy rain possible"）のみを返却するようにします。

invokeポリシーの後処理として、set-variableポリシーを追加します。このポリシーで、レスポンスの本文を必要な項目に置き換える設定を行います。

messageはレスポンスの各種データを保持する変数で、requestはユーザーからの送信データを保持します。messageは参照と更新が可能ですが、requestは参照のみ可能です。

message.bodyにはWeatherAPIから取得した結果が格納されますが、JSONデータとして認識させるには、前処理としてparseポリシーが必要です。invokeとset-variableの間にparseポリシーを追加します。

parseポリシーを以下のように設定します。

これらの定義を保存・公開すると、天気のテキストのみが返されるようになります。

request

curl -X GET 'https://<ホスト>/<プロバイダーID>/sandbox/api2/weatherHistory?q=tokyo&dt=2025-09-11&hour=15' -H 'accept: application/json'

response

Patchy rain possible

おわりに

今回は、IBM API Connectを使ってバックエンドAPIとの連携や、レスポンスデータの変換を行う基本的な処理を試しました。

API Connectには、実際の業務ニーズに対応する様々な機能が備わっています。ぜひ、この記事を参考に、他の機能も試してみてください！

参考

ポリシーで選択できるノード解説
https://www.ibm.com/docs/ja/api-connect/10.0.8_lts?topic=specification-execute

コンテキスト変数
https://www.ibm.com/docs/ja/api-connect/10.0.8_lts?topic=reference-api-connect-context-variables

IBM API Connect アセンブル作成ガイド
対応しているバージョンは古いですが、全体的な考え方を捉えるには参考になります。
https://public.dhe.ibm.com/software/dw/jp/websphere/library/connectivity/apic/assemble-guide.pdf

さらに詳しい情報をお探しの方へ

IBMの最新情報、イベント情報、さらに役立つ資料は、以下のIBM Communityでも発信・格納されています。

最新のトレンドや有益な情報をチェックするために、ぜひご覧ください！

WebSphere: IBM Community - WebSphere

WebSphere関連の最新情報やディスカッション、イベント情報、技術資料を公開中！

ELM (Engineering Lifecycle Management): IBM Community - ELM

ELMに関する最新のイベント情報、ナレッジ共有、便利なドキュメントをチェック！

Integration: IBM Community - Integration

Integrationに関する最新のイベント情報、ナレッジ共有、便利なドキュメントをチェック！