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 を生成できます。これは、ポータルの [概要] タブにあります。 この API は、この同じ URL に /api を追加した URL から使用できます。

ショッピング リスト 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 プロジェクトがあります。 API には HTTP GET 関数がありません。 Azure Functions プロジェクトの API を完了し、不足している関数を追加した後、API をフロントエンド Web アプリに接続します。

Web アプリの変更をプレビューする

アプリに変更を加える前に、変更用の新しいブランチを作成することをお勧めします。 アプリの API を完成させるときに変更がいくつか加えられるため、その変更のブランチを作成します。

変更を加えた後、変更のマージを決定する前に、それらが実行されていることを確認する必要があります。 新しいブランチから main ブランチへの pull request を作成すると、GitHub アクションによってアプリと API がビルドされ、両方ともプレビュー URL にデプロイされます。 このプレビュー URL を使用すると、Azure Static Web Apps で Web アプリを実行したままで、pull request の結果を含む 2 つ目の URL を表示することもできます。

Web アプリと API 間の通信を構成する

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 エンドポイントを構成する準備が整いました。