Azure Functions を使用して API をビルドする
次に、ショッピング リスト アプリ用の API を作成します。
Azure Functions
Azure Static Web Apps の最大の利点の 1 つは、Azure Functions を使用してビルドされた Web アプリと API を一緒にホストできることです。 Azure Static Web Apps を使用すると、Web アプリの静的資産をグローバルに配布し、Azure Functions で API をホストすることができます。 この設定により、Web アプリ資産のグローバルな配布によって得られる可用性と速度を実現できます。
何を所有しないかも重要です。
フロントエンドまたはバックエンドを構成および保守するための完全なサーバーは必要ありません。 Azure Static Web Apps を使用すると、最小限の構成とメンテナンスでアプリと API を簡単に発行できます。
Azure Functions によってルート エンドポイントが提供されるので、構成または保守するための完全なバックエンド サーバーは必要ありません。需要に基づく自動的なスケールアウトおよびスケールインが提供されます。 これらの機能により、Azure Functions は、静的資産を提供するショッピング リスト Web アプリの優れた API パートナーになります。
Azure Static Web Apps を使用すると、サイトの一意の URL を生成できます。これは、ポータルの [概要] タブにあります。 この同じ URL を使用し、URL に /api を追加することで API を使用できます。
ショッピング リスト API
ユーザーはショッピング リスト アプリを使用して、リストから項目を取得、追加、更新、削除できます。 そのため、API にこのようなニーズに合うエンドポイントが必要であるということは理にかなっています。
次の 4 つのエンドポイントを作成します。
| メソッド | ルート エンドポイント | 完全な API エンドポイント |
|---|---|---|
| GET | products |
api/products |
| POST | products |
api/products |
| PUT | products/:id |
api/products/:id |
| DELETE | products/:id |
api/products/:id |
HTTP GET 要求が api/products にルーティングされることに注目してください。 api プレフィックスは、アプリの API エンドポイント用に予約されています。 サイトのニーズに合わせて他のルートを定義できますが、api は常に Azure Functions アプリを指します。
Web アプリ用の API を作成する
ここまでは、フロントエンド フレームワークを使用してきました。 すぐに、API を追加してフロントエンド アプリに接続できます。 リポジトリには、不完全な Azure Functions プロジェクトと、製品の PUT、POST、および DELETE 用の HTTP エンドポイントが格納される api-starter フォルダーがあります。
API には HTTP GET 関数がありません。 Azure Functions プロジェクトの API を完成させ、不足している関数を追加します。 その後、API をフロントエンド Web アプリに接続します。
Web アプリへの変更のプレビュー
アプリに変更を加える前に、変更用の新しいブランチを作成することをお勧めします。 アプリの API を完成させるために変更をいくつか加えるため、その変更のブランチを作成する必要があります。
変更を加えた後、変更のマージを決定する前に、それらが実行されていることを確認する必要があります。 新しいブランチからメイン ブランチへの pull request を作成すると、GitHub アクションによってアプリと API が構築され、プレビュー URL にデプロイされます。 この機能により、Azure Static Web Apps で Web アプリを実行したままで、pull request の結果を含む 2 つ目のプレビュー インスタンスも表示することができます。
Web アプリと API 間の通信
Azure Functions を使用して API をローカルで実行すると、既定ではポート 7071 で実行されます。 Web アプリは別のローカル ポートで実行されています。 Web アプリで、そのポートから API のポート 7071 に HTTP 要求を送信しようとした場合、この要求はクロスオリジン リソース共有 (CORS) と呼ばれます。 API サーバーによって要求の続行が許可されない限り、ブラウザーではその HTTP 要求が完了されません。
Azure Static Web Apps に発行するときに、CORS について心配する必要はありません。 リバース プロキシを使用して Azure 上の API と通信できるように、Azure Static Web Apps で自動的にアプリが構成されます。 リバース プロキシを使用すると、Web アプリと API を同じ Web ドメインのものであるかのように見せることができます。 そのため、ローカルで実行する場合にのみ CORS を設定する必要があります。
次のステップ
これで、API を作成し、ショッピング リスト アプリの HTTP エンドポイントを構成する準備が整いました。