6. 综合练习:调通一组 CRUD 接口
这是什么:本章把前五章拧成一股绳——对模拟「文章管理」的公开接口 https://jsonplaceholder.typicode.com/posts 做一轮完整 CRUD(Create / Read / Update / Delete,即增、查、改、删的合称)。
为什么用:单发请求你会了,但真活的形态是「一套接口本体上的连续操作」:查了再发、发完再改、改完再删。工作里说的「调接口」,指的就是这套流程的熟练度。
如何用:复用第 4 章的集合与环境,四步走完 CRUD;Post 的新文章用 Tests 把 id 存进环境变量,让下一个请求用 {{new_id}} 接棒——变量传递就是接口串成链的关键。
6.1 准备:环境 + 集合
- 环境「练习环境」:变量 base_url =
https://jsonplaceholder.typicode.com - 新建集合「文章管理」,放入四个请求:
| 请求名 | 方法 | URL |
|---|---|---|
| 查文章 | GET | {{base_url}}/posts/1 |
| 发文章 | POST | {{base_url}}/posts |
| 改文章 | PUT | {{base_url}}/posts/1 |
| 删文章 | DELETE | {{base_url}}/posts/{{new_id}} |
「发文章」的 Body 照第 3 章选 raw + JSON(下一节给内容)。
6.2 第 1 步:GET 验活
点「查文章」→ Send,状态 200 就说明服务活着。顺手把断言配上(Scripts → Post-response):
pm.test("状态码是 200", function () {
pm.response.to.have.status(200);
});
pm.test("id 是 1", function () {
pm.expect(pm.response.json().id).to.eql(1);
});
✓ 状态码是 200
✓ id 是 1
2/2 Passed
6.3 第 2 步:POST 新建,并存下 id
切到「发文章」,Body 填:
{
"title": "青蛙的文章",
"body": "Postman CRUD 练习",
"userId": 1
}
在它的 Post-response 区写关键一步——把返回的 id 存进环境变量:
pm.test("状态码是 201", function () {
pm.response.to.have.status(201);
});
pm.test("保存新文章 id 到环境变量", function () {
const json = pm.response.json();
pm.environment.set("new_id", json.id);
});
Send 后你会看到响应带上了新编号:
{
"title": "青蛙的文章",
"body": "Postman CRUD 练习",
"userId": 1,
"id": 101
}
同时脚本结果 2/2 通过——new_id 已经悄悄存进当前环境了。
6.4 第 3 步:PUT 修改
「改文章」:方法 PUT,URL {{base_url}}/posts/1,Body 填改好的完整内容(title 换成「青蛙改过的标题」),Send → 200。
小心一个坑:这个假服务是「假存」——POST 返回的 id 101 实际并不存在。对它发 PUT 是没排练过的剧情。真实后端里,这一步就该写
{{base_url}}/posts/{{new_id}},一路用变量串下去。
6.5 第 4 步:DELETE 收尾
「删文章」:方法 DELETE,URL 正是 {{base_url}}/posts/{{new_id}}——点 Send 前确认 URL 栏里花括号已解析成 101。这一次,请求地址真正由上一个请求的响应喂出来了:
{}
状态 200、空包裹作证——假服务不真删,但链路是真通了:查 → 发(存 id)→ 改 → 删,四步一气呵成。
6.6 收尾:从过家家到真后端
走完四步,你已经把「调接口」这门手艺的结构全摸过一遍。毕竟刚才的接口是「假装存了」——下一步让它落地:跟着本站 Flask 教程自己起一个真后端,把练习地址从 jsonplaceholder 换到自己的服务器。Flask 数据库一节有现成的数据库接口等着你用 Postman 验收。
记忆口诀:GET 验活,POST 建、存 id,PUT 改要整箱,DELETE 收尾;{{new_id}} 一串,接口变流水线。
6.7 动手改
- 把「改文章」的 URL 换成
{{base_url}}/posts/{{new_id}}亲眼看服务器回什么,想明白为什么真实后端不会有这个坑 - 给四个请求全部配齐断言,用 Collection Runner 一把梭到全绿
- 给「删文章」补一条断言:
pm.expect(pm.response.json()).to.eql({})——验证那封「空包裹」,体会 eql 对整个对象的用法
6.8 小结
- 一轮 CRUD:GET 验活 → POST 建立+存 id → PUT 整改 → DELETE 收尾
pm.environment.set("new_id", json.id)是让请求们接力的关键一行- 假服务的边界要心里有数:存的不真存、删的不真删,链路本身是真的
本教程完 · 下一步 用 Flask 做个真后端,返回开发工具板块总览 🐸