-
Notifications
You must be signed in to change notification settings - Fork 0
MS_APIGateway
-
TOP > インフラストラクチャ > 通信技術 > HTTP > WebAPI
- API Gateway
- クロス ドメイン接続
- WebAPIの認証
API Gateway について。
複数の WebAPI の前段に置く単一の入口であり、
個々のサービスから横断的関心事を引き剥がすためのコンポーネントである。
移行メモ: 元ページは「API Gateway について。」と参考リンクのみの ほぼ見出しだけのページであった。 作者の意図(他 Wiki と Azure API Management への誘導)を残しつつ、 最低限の内容を補った。
なお、開発基盤部会 Wiki 側にも同名ページ「API Gateway」が存在するため、 本ページのファイル名には AGENTS.md の規約に従い
MS_プレフィックスを付与している。
| 役割 | 内容 |
|---|---|
| ルーティング | パスやホストで背後のサービスへ振り分ける(リバース プロキシ) |
| 認証・認可 | トークン検証を集約する(WebAPIの認証) |
| レート制限・クォータ | 呼び出し回数を制御する(429 を返す) |
| プロトコル変換 | REST ⇔ SOAP、gRPC ⇔ gRPC-Web など |
| キャッシュ | キャッシュ・コントロールのHTTPヘッダに基づく応答キャッシュ |
| 横断的処理 | ログ・トレース、CORS (Cross-Origin Resource Sharing)、セキュリティ強化のHTTPヘッダの付与 |
| バージョニング | 複数バージョンの並行公開 |
マイクロサービス構成では、クライアントが多数のサービスを直接叩くと
接続先の管理・認証・CORS 設定が各サービスに散らばる。
API Gateway を置くことで、これらを 1 箇所に集約できる。
補足: 一方で、API Gateway は 単一障害点かつ変更の集中点になりやすい。 ここに業務ロジックを書き始めると、 かつての ESB と同じ問題(Gateway が肥大化し、 サービスの独立デプロイができなくなる)を再現する。 Gateway に置くのは横断的関心事だけに留めること。
| 分類 | 例 |
|---|---|
| マネージド サービス | Azure API Management(MS_AzureAPIManagement.md)、Azure Front Door、AWS API Gateway |
| セルフ ホスト | Kong、KrakenD、Envoy、NGINX |
| .NET ライブラリ | YARP(Yet Another Reverse Proxy)、Ocelot |
補足(最新化): .NET で自前の Gateway / リバース プロキシを 組む場合、現在の第一候補は Microsoft 製の YARP である (Ocelot より後発で、Microsoft 自身が本番運用している)。 ただし、認証・レート制限・課金・開発者ポータルまで必要なら、 素直に Azure API Management のようなマネージド製品を使うほうが早い。
- WebAPI
- WebAPIの認証
- API Gateway(開発基盤部会 Wiki)
- Azure API Management とは - Microsoft Learn
- YARP - Microsoft Learn
Tags: クラウド, .NET開発, OWIN, ASP.NET, ASP.NET Web API
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。