使用 Azure Functions 建置 API
現在可以為您的購物清單應用程式建立 API。
Azure Functions
Azure Static Web Apps 的最大優點之一，就是它會一起裝載您的 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 |
| 郵件 | products |
api/products |
| PUT | products/:id |
api/products/:id |
| 刪除 | 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，因此您應該為這些變更建立分支。
在您進行變更後，最好先觀察這些變更的執行情況，再決定是否要合併。 一旦您從新的分支建立提取要求至 主要 分支，GitHub Action 就會建置您的應用程式和 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 端點。