Azure API Management 概要
具備機能の調査
特に、用途が不明だった以下の機能について調査を行った。
GPTクンの回答
API Managementの中で「products」と「サブスクリプション」は、特定の利用ケースに対応するための機能です。以下に、あなたのAPIの利用シーンにおいてそれぞれの機能の役割や適用性について説明します。
- Products（プロダクト）
役割： Productsは、APIをまとめて管理し、開発者や特定のグループ向けに提供するための仕組みです。各Productには1つ以上のAPIが含まれ、利用者はProductsを申し込むことでAPIにアクセスできるようになります。
利用シーン：
Productsは、APIを特定の利用者やグループに提供するために使用します。例えば、同じAPIでも無料プラン、有料プラン、特定の企業向けプランなど、異なるProductsに分けて提供できます。
利用者がProductsに対してサブスクリプション（購読）を行い、承認されることでAPIへのアクセスが可能になります。
今回の利用シーンでの判断：
あなたが述べたように、不特定多数の一般利用者が対象であり、開発者や特定のグループ向けのサービスではない場合、Productsの利用は必要ないと考えられます。Productsは、より細かい制御が必要な場合に役立ちます。
- サブスクリプション
役割： サブスクリプションは、APIにアクセスする権限を制御するための仕組みです。利用者がProductsにサブスクリプションを行い、承認されることでAPIにアクセスできます。
利用シーン：
サブスクリプションは、APIに対するアクセス制御や利用制限（クォータ）を管理するために使用されます。
特定の利用者やグループに、異なるサブスクリプションプランを提供することができます。有料プランや無料プランなどがあります。
今回の利用シーンでの判断：
B2Cで払い出したトークンを使用してJWT認証を行う場合、サブスクリプションは必ずしも必要ではありません。B2Cがトークンを発行し、それに基づいてアクセスを管理する場合、サブスクリプションによるアクセス制御が既に行われている可能性があります。ただし、API Managementにおいてクォータの制御や特定の利用者に対する追加の制約が必要な場合は、サブスクリプションの利用を検討することがあります。
一般的な「Products」の利用例：
開発/テスト環境と本番環境の分離： 同じAPIでも、開発者向けのProductsと本番向けのProductsを分けて提供し、開発者が本番環境に影響を与えないようにする。
有料プランと無料プランの提供： 同じAPIでも、有料プランと無料プランを提供し、利用者がプランに応じてサブスクリプションする。
- products
特定のグループや開発者向けにAPIを公開するときに使う。開発者にとっては、APIの利用承認を挟むイメージ。また、開発者は、開発者ポータルからAPIの仕様を確認することで学習を進めることができる。必ずしも、一般向けのAPI作成ではなく、開発者目線でのAPI公開もできる。
プロダクト自体には、ポリシーで利用制限のような機能も存在する。ポリシーであれば、製品に設定ではなくAPIに設定もできる。
個人的な見解として、いくつもAPIがあって、それぞれに同じポリシーが含まれるときとかは、製品化でグルーピングしてポリシーを共通的に設定するのもありかもしれない。
確かに、以下を見ると、APIより上位層でのアクセス制"限"ができるようである。さらに、アクセス制"御"（RBACのようなもの）も製品独自で備わっている。
このあたりは、以下で丁寧に解説されている。
- サブスクリプション
公開APIの保護（アクセス制限やクォーター制限）に使われる。サブスクリプションキーをリクエストヘッダーに含めないAPI呼び出しは拒否をするといったことができる。
サブスクリプションキーは、API毎に作成こともできるし、すべてのAPIにアクセスできるキーを払い出すこともできる。
別の認証方法（JWT認証）を使う場合には、サブスクリプションキーの要求をOFFにできる。
- ポリシー
APIの保護に使われる。例えば、Azure AD B2CなどのIDプロバイダーからの認証トークンを持たない場合には、接続を拒否（401コード）といった動きができる。
参考資料
Azure API Management のチュートリアルで学んだこと
API作成までの大まかな流れ
- API Managementのリソース作成
- 左ペインからAPIの作成。バックエンドの登録を行う。チュートリアルでは用意されたAPIのURLを入力したが、App ServiceなどをバックエンドとしてURLを入力可能。
- 「製品」に登録をする。← 実施しないと、開発者がAPIをサブスクライブできないので注意。
製品にポリシーの適用など、より高度な設定ができるようになる。
ポリシーで実施できること
以下は一例である。
- レート制限（呼び出し元のリクエスト制限）
- ヘッダ変換（呼び出し元に見せたくないヘッダの削除、URLの書き換え）
バージョンとリビジョンの違いとは？
- バージョン
同時に複数のバージョンを公開したいときに利用する。（最新がv2で、一部の過去の機能は残したv1を公開したままにする）
バージョンを作成することで、/{バージョン識別子}がURLに付与される。画像の場合は、v2というバージョンを作成した。
- リビジョン
App Serviceのデプロイスロットのようなイメージである。変更前の動作確認であったり、ブルーグリーンデプロイのようなことが可能と認識している。
リビジョンを作成することで、URLに;rev={num}が付与される。
開発者ポータルとは？
利用者が、自分が使うAPIの仕様や、実際に開発者ポータル場からAPIを実行してみることができるサイトである。使いたいAPIの利用申請を上げて、承認後にサブスクリプションキーを確認するといったポータルサイトとしても利用する。（バグ報告もできるらしい）
https://{APIMリソース名}.developer.azure-api.net/
という形式でURLが提供される。そのため、Azure Portalではない、APIで独立したポータルをAPI利用者に展開するときに使われるのだろう。
疑問点
「製品」画面上でもポリシーを設定できるし、「API」画面上でもポリシーを設定できる。使い分けは何だろうか？
→ 製品には複数のAPIを含めることができるため、API間で共通したものは、製品上のポリシーで定義。個別のAPIの中に閉じたポリシーは、各API画面上で設定するイメージだろうか。（APIの中の各メソッドレベルのポリシー定義も同じ話）。
(2023/07/01追記）
疑問についは以下の記事や公式ドキュメントの解説で解消される。
簡単にまとめると以下の通り。
- ポリシーには適用スコープが存在する。以下の順番でポリシーが適用される。
- グローバル
- 成果物（製品）
- API
- オペレーション（GETとか）
※ ワークスペースはポリシーの適用方法のドキュメントに記載がなかったため省略。
- 各ポリシー（XML）で親ポリシーを呼びだす時には、<base />を挿入する。ただし、挿入場所には注意が必要。ポリシーは記述順から適用されていくため、何も考えずに末尾に追記すると適用されない可能性が非常に高い。
参考URL
- チュートリアル全般
- リビジョンとバージョンの用途分け
- ポリシーの適用範囲
追加確認
リビジョンって何のためにあるのか再確認。後ろにあるAppServiceとかを更新すればいいのではないか。同時に２つ持っておきたいとか？
Discussion