Postman：API 开发环境

如果你以任何身份与 API 合作过，你几乎肯定听说过——或者已经在使用——Postman。十多年前，它始于一个简单的 REST 客户端，一个 side project 用来解决开发者自己的痛点，如今已发展成为超过 4000 万开发者使用的不可或缺的工具。

今天，Postman 远不只是一个 API 客户端。它是一个全面的 API 开发环境，旨在支持 API 生命周期的每个阶段，从设计和模拟到测试和文档。本指南将引导你了解 Postman 的核心功能，并展示它如何与 API 网关完美配合，创建稳健、端到端的 API 策略。

什么是 Postman？从简单的 API 客户端到完整的平台

从本质上讲，Postman 是一个用于向 API 发出 HTTP 请求的应用程序。在早期，它之所以流行，是因为它为开发者以前使用 cURL 等命令行工具或编写临时脚本处理的任务提供了一个简洁的图形用户界面。你可以轻松地构建一个包含正确 方法（GET、POST 等）、URL、请求头和请求体的请求，然后以格式精美的方式检查响应。

然而，当它演变成一个协作平台时，它的真正力量才显现出来。Postman 现在是一个你可以设计、测试、记录和共享 API 的环境，确保从第一行代码到最终生产部署的一致性和质量。它在单一、统一的工作流中连接整个 API 生命周期。

核心工作流：从单个请求到强大的集合

进入 Postman 的旅程始于一个单独的请求，但它的力量在于组织和可重用性。

1sequenceDiagram
2    participant User
3    participant Postman
4    participant API
5
6    User->>Postman: 1. 构建请求（方法、URL、认证、请求体）
7    Postman->>API: 2. 发送 HTTP 请求
8    activate API
9    API-->>Postman: 3. 接收 HTTP 响应（状态、请求体、请求头）
10    deactivate API
11    Postman-->>User: 4. 显示格式化响应

Postman 集合的强大功能

一个 Postman 集合是一组已保存的请求。把它想象成你 API 的可执行文件夹。我们常见的集合可能包含对以下内容的请求：

1. 进行认证以获取令牌。
2. 使用令牌创建新资源。
3. 获取该资源以验证其创建。
4. 更新资源。
5. 删除资源。

通过将这些请求分组，你创建了一个描述 API 如何工作的活文档。你可以为每个请求添加描述，与团队共享集合，甚至从中生成完整的 API 文档。

使用变量和环境实现动态工作流

硬编码 URL 或 API 密钥等值是低效且有风险的。Postman 使用变量解决了这个问题。你可以定义一个像 {{baseUrl}} 这样的变量，并在所有请求中使用它。

为了管理这些变量，Postman 使用环境。你可以为不同的设置定义不同的环境：

• 本地开发： baseUrl = http://localhost:3000
• 预发布环境： baseUrl = https://staging-api.yourcompany.com
• 生产环境： baseUrl = https://api.yourcompany.com

通过简单地切换活动环境，你可以在不同的部署上运行相同的请求集合，而无需更改单个请求。

自动化你的工作流：API 测试和模拟

这就是 Postman 从一个简单的客户端转变为一个真正的 API 开发和测试工具的地方。

自动化 API 测试

在任何请求的 Tests 选项卡下，你可以编写在收到响应之后执行的 JavaScript 代码。Postman 提供了一个强大的 pm 库来进行断言。

例如，在发送 GET /users/123 请求后，你可以编写测试以确保：

• 响应成功。
• 响应是有效的 JSON。
• 用户名是你所期望的。

1// Postman 测试示例
2pm.test("状态码为 200", function () {
3    pm.response.to.have.status(200);
4});
5
6pm.test("响应是有效的 JSON", function () {
7    pm.response.to.be.json;
8});
9
10pm.test("用户名正确", function () {
11    const jsonData = pm.response.json();
12    pm.expect(jsonData.name).to.eql("Jane Doe");
13});

这些测试与你的集合中的请求一起保存。然后，你可以使用 Collection Runner 自动执行整个集合并获得详细的报告，显示哪些测试通过或失败，这使其非常适合回归测试和 CI/CD 流水线。

使用模拟服务器进行并行开发

软件开发中一个常见的瓶颈发生在前端团队被阻塞，等待后端团队构建和部署 API 时。Postman 的模拟服务器消除了这个问题。

你可以创建一个模拟服务器，通过为特定端点返回预定义的示例响应来模拟 API。然后，前端团队可以针对这个模拟服务器构建他们的应用程序。只要真实的 API 一旦构建完成就遵守相同的契约（请求和响应中的相同结构），集成将是无缝的。

Postman 和你的 API 网关：强大的伙伴关系

在 API7.ai，我们看到了一个明确而有力的区别：Postman 对于构建和测试 API 的功能至关重要，而像 Apache APISIX 这样的 API 网关对于保护和管理 API 如何向外界公开至关重要。它们是同一枚硬币的两面。

1graph TD
2    subgraph 开发和测试 [开发和测试工作流]
3        Developer --> Postman;
4    end
5
6    subgraph 预发布和生产 [预发布/生产环境]
7        Postman --> APISIX[("API 网关<br>Apache APISIX")];
8        APISIX --> Upstream[你的后端服务];
9    end
10
11    linkStyle 1 stroke:#007bff,stroke-width:2px;

以下是它们在典型工作流中的协同工作方式：

1. 配置网关策略： 你在 Apache APISIX 中配置一个路由并应用用于安全、流量控制和可观察性的插件。例如，你可能会添加一个 速率限制插件 以允许每分钟仅 5 个请求。
2. 使用 Postman 进行测试： 然后，你转向 Postman 以验证策略是否完全按预期工作。

实践示例：测试速率限制插件

想象一下，你在 Apache APISIX 中的 /products 端点上设置了每 10 秒 2 个请求的限制。

1. 在 Postman 中，你发送一个 GET 请求到 https://api.yourcompany.com/products。它通过 APISIX，命中你的服务，你得到一个 200 OK 响应。
2. 你立即再次发送它。200 OK。
3. 你在 10 秒窗口内第三次发送它。这一次，Apache APISIX 拦截请求，不是转发它，而是立即返回一个 429 Too Many Requests 状态码。

你刚刚使用 Postman 验证了你的网关是否已准备好投入生产。你可以使用相同的方法来测试认证（在没有密钥的情况下获得 401 Unauthorized）、转换和其他关键任务策略。

结语：将 Postman 集成到你的现代 API 生命周期中

Postman 已经巩固了其作为任何使用 API 的人的基础工具的地位。它从一个简单的 REST API 客户端演变为一个用于设计、模拟、测试和协作的综合平台，使开发者能够更快地构建更高质量的 API。

但是，构建一个伟大的 API 只是成功的一半。当你使用 Postman 完善其功能时，请记住，API 网关为生产提供了必要的安全、可靠性和可观察性层。Postman 验证 API 的契约，而网关强制执行其使用的策略。