はじめに
Webアプリを運用していると、例えば「アプリのバージョンアップで旧アプリから新アプリに移行し、旧アプリを閉塞させたい」といったケースがあるかと思います。
その際、新アプリのリリース後にユーザーが間違えて旧URLでアプリにアクセスしてしまうこともあるかと思いますが、そういった場合は適切に新URLにリダイレクトさせる必要があります。
こういったリダイレクトの処理はAzure API Managementでポリシーの設定を利用することにより解決できます。
リダイレクトの機能のみですとAzure FrontDoorでもサポートされていますが、API Managementの場合は独自のロジックを組み込めるため、より細かいリダイレクトのポリシーを実現することができます。
ユーザーが旧アプリのURLにアクセスした場合であっても新アプリにリダイレクトさせ、旧アプリの実質的な閉塞が可能です。
前提
-
新アプリ/旧アプリは、それぞれApp Services等に既にデプロイ済みとします。
-
API Managementでは、旧アプリ用/新アプリ用2つのAPIがあるとします。
- 本記事ではそれぞれの設定は下記の通りとします。
- 旧アプリ
- Base URL:
https://<API Managementドメイン>
- Base URL:
- 旧アプリ
- 本記事ではそれぞれの設定は下記の通りとします。
-
API URL suffix:なし
![5-999c32ce-5cac-429f-9542-fea899f23996.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/398865/51a26ee9-36a6-64f6-2e86-abd33b468237.png) * 新アプリ * Base URL: `https://<API Managementドメイン>/v2` * API URL suffix:v2 ![6-1367eb4e-2862-42ca-bf73-f0fd71a40e30.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/398865/41da1a71-fb77-8987-9cf7-897addfb8390.png)
API Managementポリシー設定
旧アプリ側のGETオペレーションのInbound processingポリシーに下記の要素を追加します。
Azure PortalのUIではこちらを選択するとポリシーの編集画面になります。
<policies>
<inbound>
<base />
<!-- 追加 -->
<return-response>
<set-status code="303" reason="Redirecting" />
<set-header name="Location" exists-action="override">
<value>@{
return "/v2";
}</value>
</set-header>
</return-response>
<!-- /追加 -->
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
解説
ポリシーの中でも、今回追加した箇所をピックアップします。
<return-response>
<!-- 303ステータスコードを返す -->
<set-status code="303" reason="Redirecting" />
<!-- ヘッダーのLocationを編集 -->
<set-header name="Location" exists-action="override">
<value>@{
return "/v2";
}</value>
</set-header>
</return-response>
上記では、return-response
ポリシーを利用してAPI Managementからのレスポンスをカスタマイズしています。
今回カスタマイズしているのは、下記の2点です。
-
set-status
でのステータスコードの定義-
303
でリダイレクトのコードを指定
-
-
set-header
でのレスポンスヘッダーの上書き-
Location
ヘッダーでリダイレクト先のパスを指定
-
参考:https://learn.microsoft.com/ja-jp/azure/api-management/return-response-policy
動作確認
API Managementで変更を適用後、旧アプリへのURLにアクセスしてみましょう。
- URL例:
https://<API Managementサービス名>.azure-api.net/
アクセス後にURLを確認すると、新URLにリダイレクトできていることが確認できます。
さらにブラウザの開発者ツールでネットワークログを確認すると、下記のログが確認できます。(キャプチャはChromeのネットワークログです)
- リダイレクトのログ
- URL:
https://<API Managementサービス名>.azure-api.net/
- ステータス:303
- URL:
- 新URLのログ
- URL:
https://<API Managementサービス名>.azure-api.net/v2
- ステータス:200
- URL:
1.のログの詳細を見ると、レスポンスヘッダーのLocationに新アプリのパスがあることも確認できます。
まとめ
今回はAPI Managementポリシーを利用したリダイレクト処理をご紹介しました。
もちろんリダイレクト処理をアプリ側のソースコードで定義することもできますが、API Managementで定義してしまえばアプリのソースコードやフレームワークに依存せずにリダイレクト処理ができ、アプリへのアクセス前に処理が実行されますので比較的リダイレクト処理が速くなります。
また、API Managementポリシーでは独自APIの呼び出しもサポートされています。
次回は独自APIを組み込み、条件に応じてリダイレクトさせる方法についてご紹介しようと思います。