はじめに
IBM Cloud上のAPI Connectを試してみた時の作業ログです。
今回はAPI Connect上に登録されたAPIの管理操作について実施してみます。
関連記事
IBM API Connect 関連メモ - (1)既存REST APIの取り込み
IBM API Connect 関連メモ - (2)API Connectツールキットを使用したNode.jsアプリ作成(Loopback)
IBM API Connect 関連メモ - (3)カタログ、開発者ポータルの構成
IBM API Connect 関連メモ - (4)各種APIの管理
IBM API Connect 関連メモ - (5)Secure Gateway経由でのz/OS Connectとの連携
IBM API Connect 関連メモ - (6)API Connect-z/OS Connect間TLS接続
IBM API Connect 関連メモ - (7)z/OS Connect 基本認証 + ID伝播
IBM API Connect 関連メモ - (8)z/OS Connect 連携におけるインターフェースの浄化
IBM API Connect 関連メモ - (9)z/OS Connect 連携まとめ
チュートリアル実施
クライアント ID とクライアント秘密鍵による API の保護
参考: クライアント ID とクライアント秘密鍵による API の保護 (IBM Cloud を使用する場合)
セキュリティーの定義
変更を保存します。
アセンブルからテスト
クライアントID, 秘密鍵を変更すると、401(Unauthorized)の応答が返ります。
カタログ(Sandbox)からテスト
探索 - Sandboxを選択
Client ID, Client secret指定でcurrentをテスト => OK
Client ID, Client secretを無効なものに変更した場合は401(Unauthorized)の応答が返ることを確認
Client ID, Secretの確認
テスト時には勝手に引っ張ってきてくれたけど、こちらから確認可能です。
ダッシュボード - カタログ(Sandbox) - 設定 - 概要から確認可能です。
レート制限のセットアップ
参考: レート制限のセットアップ
デフォルトプランの確認
ドラフト - 製品 - Weather Provider API product (weather-provider-api-product) 1.0.0 を選択
プランの項目を確認します。
デフォルトのプランでは、1時間あたり100回の制限が設けられています。
新しいプランの作成
以下のようなプランを作成します。1分あたり10回の制限を指定します。
カタログへのステージングと公開
変更を保存して、カタログ"Sandbox"にステージングします。
ダッシュボード - カタログ"Sandbox"を選択し、先ほどステージングされた製品を公開します。
開発ユーザーからのAPIの利用
管理者とは別のメールIDを使用して開発ユーザー(APIコンシューマー)を作成し、API利用の流れを確認してみます。
参考: API の検出
開発ユーザーの作成
Sandboxの開発者ポータルに接続して、Create an accountをクリック
指定した開発者ユーザーとしてのメールアドレスにメールが飛ぶので、そこに指定されているURLをクリックしてユーザーを有効化すると、開発者ポータルに開発ユーザーとしてログインすることができます。
開発者ポータルでのアプリケーション作成
アプリケーションのメニューで、新しいアプリケーションの作成をクリック
この内容をコピーしておきます。
APIのサブスクライブ
API製品から Weather Provider API productを選択し、上で作成したDemoプランの配信登録をクリックします。
API呼び出しテスト
左側のメニューからWeather Provider APIを選択
GET/currentのこの操作を試してみるの下にある、クライアントIDにMy Mobile App, クライアントシークレットに上でメモったSecretを指定し、zipcodeに90201を指定して、操作の呼び出しをクリック
汎用的なREST Clientツールからテスト
上で設定したセキュリティーとレート制限を、汎用的なREST APIテストツールを使って試してみたいと思います。
ChromeのTalend API TesterというテストツールからAPIを発行してみます。
Client ID, Secretを適当な値にすると401(Unauthorized)が返るので、きちんとセキュリティーの設定が効いていることが確認できました。
次に、立て続けに実行して、1分以内に10回以上実行してみます。
プランで指定された流量制御の制限にひっかかると、HTTPレスポンスコードとして429(Too Many Requests)が返されました!
APIのバージョン管理
APIを変更した場合にその変更を反映させる操作として、置換(Replace)と取り替え(Supersede)という2種類があるようです。
それぞれのチュートリアルの内容を見ると、前者がサブスクリプションのマイグレーションまで自動で実行される、後者がサブスクリプションのマイグレーションは手動で実行しなければならないっぽい。
操作 | 旧バージョンの製品ステータス | 新バージョンの製品ステータス | サブスクリプションのマイグレーション |
---|---|---|---|
置換(Replace) | 廃棄 | 公開 | 強制的に自動実行される |
取り替え(Supersede) | 非推奨 | 公開 | 手動で実行する必要あり |
"置換"の方はあるタイミングで新しいAPIに完全に移行、"取り替え"の方は旧APIと新APIが共存しながら適宜移行していくような使い分けのようです。
API製品の置換(Replace)
参考: API 製品の置換
APIのバージョン変更
ドラフトからAPI - Weather Provider APIを選択し、バージョン情報を1.0.0 => 2.0.0に変更し、保存
製品のバージョン変更
ドラフトから製品 - Weather Provider API productを選択し、バージョン情報を1.0.0 => 2.0.0に変更し、保存
置換(Replace)実行
バージョンを変更した製品をカタログ"Sandbox"にステージング
ダッシュボードからカタログ"Sandbox"を選択し、ステージングされたV2.0.0の製品のメニューから「既存の製品の置換」を選択
旧バージョンの製品が廃棄済みとなり、新バージョンの製品が公開済みとなりました。
開発者ポータルでの確認
開発ユーザーで開発者ポータルにログインしてみると、製品、APIともに2.0.0になっていました。
API製品の取り替え(Supersede)
参考: API 製品の取り替え
APIのバージョン変更
ドラフトからAPI - Weather Provider APIを選択し、バージョン情報を2.0.0 => 3.0.0に変更し、保存
製品のバージョン変更
ドラフトから製品 - Weather Provider API productを選択し、バージョン情報を2.0.0 => 3.0.0に変更し、保存
取り替え(Supersede)実行
バージョンを変更した製品をカタログ"Sandbox"にステージング
ダッシュボードからカタログ"Sandbox"を選択し、ステージングされたV3.0.0の製品のメニューから「既存の製品の取り替え」を選択
旧バージョンの製品が非推奨となり、新バージョンの製品が公開済みとなりました。
開発者ポータルでの確認(1)
この時点で、開発ユーザーで開発者ポータル画面を確認すると...
アプリケーションの項目を見ると、"新しいバージョンが公開されています"というメッセージが出ています。
マイグレーションのボタンもあるので、開発者側が手動でマイグレーションすることもできそうです。
API製品を見ると、V2.0.0, V3.0.0両方表示され、V2.0.0は非推奨と記載されています。
サブスクリプションのマイグレーション
管理者側のIBM Cloudの画面に戻って、ダッシュボードからカタログ"Sandbox"を選択し、コミュニティーのメニューを選択します。
サブスクリプションから、Weather Provider API product 2.0.0, Demoの右側のメニューから管理を選択します。
開発者ポータルでの確認(2)
再度、開発ユーザーで開発者ポータルを確認してみます。
アプリケーションには新しい製品のプランが紐づいています。
API製品には新バージョンの製品のみ表示されるようになりました。
分析
参考: 基本的な分析を行って洞察を深める
ダッシュボードからカタログ"Sandbox"を選択し、分析を選択します。
右上のTimepickerアイコンから参照範囲を指定します。
デフォルトでは、利用頻度上位5つの製品、APIがグラフ表示されます。