理解 REST API 请求
在打开 Postman 之前，先确定 API 需要什么以及应该返回什么。请求通常包含 HTTP 方法、URL、请求头、查询参数，有时还包含请求体。例如，产品 API 可能使用 GET https://api.example.com/products/42 来获取产品 42，而 POST https://api.example.com/products 则用于创建新产品。
从 API 文档开始，记下所需的方法、端点、身份验证方式和数据格式。确认服务需要 JSON、表单数据，还是 category=books 之类的查询参数。做好这些准备可以避免初学者常犯的错误：在不知道究竟是哪一部分导致失败的情况下，同时修改多个设置。
创建 Postman 工作区和环境
为项目创建一个 Postman 工作区，并将请求按 Users、Products 和 Orders 等类别分组到文件夹中。将相关请求放在一起，可以更轻松地重复工作流程并比较结果。小型项目可能只需要十个请求，但当集合增长到数十个端点时，清晰的组织方式就会变得非常有价值。
对于开发、预发布和生产环境之间会变化的值，请使用环境变量。不要在每个请求中重复输入完整的服务器地址，而是将其存储为 base URL 变量，并以一致的方式引用。相同的方法也适用于访问令牌、用户 ID 或 API 版本，同时可以减少误将请求发送到错误服务器的情况，并避免反复编辑。
先发送 GET 请求
GET 请求是一个很有用的初步检查方式，因为它通常只读取数据而不会更改服务器。输入端点，选择 GET，添加所需的授权信息，然后发送请求。如果端点是 https://api.example.com/users/15，请确认响应代表的是用户 15，而不只是确认服务器返回了某些内容。
发送请求后，检查状态码、响应时间、请求头和响应正文。200 状态码通常表示成功，但你还应确认 id、email 或 createdAt 等字段的类型和值是否符合预期。如果响应是空数组，请先对比查询参数和测试数据，再判断 API 是否出现故障。
安全地测试 POST、PUT 和 DELETE
只有在读取操作正常后，才编写会更改数据的请求。对于 POST 请求，请选择正确的请求体格式，通常是原始 JSON，并发送一个小型且有效的负载，例如包含产品名称、价格和库存数量。确认服务器返回适当的创建响应，例如状态码 201，并检查返回的记录是否包含自动生成的标识符。
应像有意测试有效数据一样，有意测试无效数据和边界数据。尝试缺少必填名称、负价格、长度极大的描述或无效日期，然后检查 API 是否返回清晰的 4xx 响应，而不是创建损坏的数据。对于 PUT、PATCH 和 DELETE 请求，应尽可能使用专用的测试记录，以免实验修改或删除真实的客户信息。
检查状态码、请求头和 JSON
不要仅根据状态码判断请求是否成功。检查响应头中的内容类型、缓存行为、请求标识符和速率限制信息，然后在预期返回 JSON 时确认响应正文是否为有效 JSON。即使响应状态为 200，但返回的是 HTML 错误页面、缺少字段或内容类型不正确，对于消费该 API 的客户端来说，仍然意味着测试失败。
针对常见的 HTTP 结果，使用符合实际情况的检查。有效登录可能返回 200，新创建的资源可能返回 201，请求无效可能返回 400，缺少凭据可能返回 401，而已通过身份验证但没有权限的用户可能收到 403。区分这些情况有助于开发者修复真正的问题，而不是反复修改请求体。
标签 :
- Web 开发
