使用 Azure Functions 建置 API
現在可以為您的購物清單應用程式建立 API。
Azure Functions
Azure 靜態 Web 應用程式的最大優點之一是，其會一併裝載您的 Web 應用程式和使用 Azure Functions 建置的 API。 Azure 靜態 Web 應用程式會全域散發您 Web 應用程式的靜態資產，並在 Azure Functions 中裝載您的 API。 利用此設定，您可以取得因全域散發 Web 應用程式資產而獲得的可用性和速度。
您未獲得的部分也很重要。
您不需要完整的伺服器，就可以設定和維護前端或後端。 使用 Azure Static Web Apps，您可獲取最佳位置: 您可以輕鬆地利用最少的設定和維護來發佈應用程式和 API。
Azure Functions 可提供您的路由端點、不需設定或維護完整的後端伺服器，並根據需求提供自動相應放大和相應縮小功能。 這些功能讓 Azure Functions 在您使用提供靜態資產的購物清單 Web 應用程式時，成為絕佳的 API 合作夥伴。
Azure 靜態 Web 應用程式會為您的網站產生唯一的 URL，您可以在入口網站的 [概觀] 索引標籤上找到此 URL。 藉由將 /api 附加至 URL，即可透過這個相同的 URL 取得 API。
您的購物清單 API
您的購物清單應用程式可讓使用者從其清單中取得、新增、更新和刪除項目。 因此，合理而言，您的 API 應具有符合這些需求的端點。
以下是您建立的四個端點:
| 方法 | 路由端點 | 完整的 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，並將之連線到您的前端應用程式。 您的存放庫具有 api-starter 資料夾，其中包含不完整的 Azure Functions 專案，以及適用於您產品之 PUT、POST 和 DELETE 的 HTTP 端點。
此 API 缺少了 HTTP GET 函式。 完成 Azure Functions 專案的 API，並新增缺少的函式。 然後，將 API 連線到前端 Web 應用程式。
預覽對 Web 應用程式所做的變更
對應用程式進行變更之前，最好先為變更建立新的分支。 由於您正在進行數個變更，以完成應用程式的 API，因此，您應為這些變更建立分支。
進行變更之後，您希望在決定合併變更之前，先看到其正在執行。 當您從新的分支對 main 分支建立提取要求之後，GitHub 動作將會建置您的應用程式和 API，並將其部署到預覽 URL。 此功能使您能讓 Web 應用程式搭配 Azure Static Web Apps 持續執行，同時還能看到第二個預覽執行個體，其中包含來自提取要求的結果。
在您的 Web 應用程式和 API 之間通訊
當您使用 Azure Functions 在本機執行 API 時，其預設會在連接埠 7071 上執行。 您的 Web 應用程式會在不同的本機連接埠上執行。 當您的 Web 應用程式嘗試從其連接埠對 API 的連接埠 7071 發出 HTTP 要求時，該要求稱為跨原始來源資源共用 (CORS)。 除非 API 伺服器允許要求繼續執行，否則您的瀏覽器會阻止 HTTP 要求完成。
發佈到 Azure Static Web Apps 時，您不需要擔心 CORS。 Azure 靜態 Web 應用程式會自動設定您的應用程式，使其可在 Azure 上利用反向 Proxy 來與您的 API 進行通訊。 反向 Proxy 讓您的 Web 應用程式和 API 看起來就像來自相同的 Web 網域。 因此，您只需要在本機執行時設定 CORS。
下一步
現在您已準備好建立 API，並為購物清單應用程式設定 HTTP 端點。