使用 Azure Functions 生成 API

3 分钟

现在可为你的购物列表应用创建 API 了。

Azure Functions

Azure 静态 Web 应用的最大优势之一是，它一起托管 Web 应用和一个使用 Azure Functions 生成的 API。 Azure 静态 Web 应用以全局方式分发 Web 应用的静态资产，并在 Azure Functions 中托管 API。通过此设置，你可获得 Web 应用资产的全局分发所带来的可用性和速度。

你未获得的内容也十分重要。

不需要前端或后端的完整服务器来配置和维护。借助 Azure 静态 Web 应用，你可以轻松发布应用和 API，只需最少的配置和维护即可。

Azure Functions 提供路由终结点，不需要完整后端服务器进行配置或维护，并且可根据需要提供自动扩大和缩小。这些功能使得 Azure Functions 成为了你提供静态资产的购物列表 Web 应用的绝佳 API 合作伙伴。

Azure 静态 Web 应用会为站点生成唯一的 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，因此应为这些更改创建分支。

进行更改之后，要在决定合并更改之前查看其运行情况。一旦您从新分支向主分支创建拉取请求，GitHub Action 会构建应用程序和 API，并将其部署到预览 URL。此功能使你可以通过 Azure Static Web Apps 让 Web 应用保持运行，同时还可以查看另一个预览实例，其中包含拉取请求的结果。

在 Web 应用和 API 之间通信

使用 Azure Functions 在本地运行 API 时，它默认在端口 7071 上运行。 Web 应用会在不同的本地端口上运行。当 Web 应用尝试从其端口向 API 的端口 7071 发出 HTTP 请求时，请求称为跨域资源共享（CORS）。浏览器将阻止 HTTP 请求完成，除非 API 服务器允许请求继续。

发布到 Azure Static Web Apps 时，无需担心 CORS。 Azure 静态 Web 应用会自动配置应用，使它可以使用反向代理与 Azure 上的 API 进行通信。反向代理可使你的 Web 应用和 API 似乎来自同一个 Web 域。因此，仅当在本地运行时，才需要设置 CORS。