3. 请求方法与请求体

这是什么：请求方法（Request Method）= 告诉服务器「我想干什么」的动词；请求体（Body）= 动词附带的「包裹内容」，最常用的打包格式是 JSON。

为什么用：只会 GET 等于只会查快递——往服务器寄一件新东西（POST）、换掉旧的（PUT）、拆掉不要的（DELETE）全做不了。后端接口十之八九要 POST 带 JSON 数据，这章是全教程用得最多的一章。

如何用：先用「快递」类比记住四种方法的分工，再对公开练习接口各发一笔 POST/PUT/DELETE，顺手把常见状态码背下来。

3.1 四种方法：查、寄、改、拆快递

方法	快递类比	一句话用途
GET	查快递	只要数据，不动它一根毫毛
POST	寄快递	往服务器交一件新东西
PUT	换整箱	把指定的那件整个替换成新的
DELETE	拆快递	把指定那件直接撤走

多数接口就靠这四个动词撑起「增删改查」全会，先记住这个分工。

3.2 动手 POST：填一段 JSON 请求体

还是那个练习服务，这次给它「寄」一篇文章：

方法下拉选 POST，URL 填 https://jsonplaceholder.typicode.com/posts
切到 Body 标签 → 选 raw（原样发送）→ 右侧格式下拉选 JSON
在文本框里输入：

{
  "title": "青蛙的第一篇文章",
  "body": "用 Postman 寄出去的",
  "userId": 1
}

点 Send

你会看到：

{
  "title": "青蛙的第一篇文章",
  "body": "用 Postman 寄出去的",
  "userId": 1,
  "id": 101
}

服务器响应了 201 状态，还替你发了编号 id: 101——意思是「包裹收下了，给你件号」。这个练习服务是假存（刷新数据就没了），但流程和真实接口一模一样。

3.3 Headers：告诉服务器寄的是什么

Headers（请求头）= 快递面单：写「这箱里是什么」的固定信息。最常见的正是 Content-Type: application/json——声明「请按 JSON 来解析我的包裹」。

你刚才其实没手动填它：当 Body 格式选成 JSON 时，Postman 会自动补这条头（切到 Headers 标签能亲眼看到一行 Content-Type）。什么时候要手动加？对接真实接口时，对方文档要求带认证头（如 Authorization）或自定义头，才在 Headers 表格里自己加一行。

3.4 状态码速查表

状态码（Status Code）= 服务器回给你的三位数暗号。先背这六个：

状态码	名字	人话
200	OK	成功
201	Created	新建成功（POST 常见）
400	Bad Request	你寄错了：格式不对、缺字段
401	Unauthorized	快递员不认识你：没登录、没凭证
404	Not Found	服务器没这个地址
500	Internal Server Error	服务器自己搞砸了：去查后端日志

规律：4 开头多半是你的请求有问题，5 开头多是服务端的问题。

3.5 把 PUT 和 DELETE 也走一遍

PUT：方法选 PUT，URL https://jsonplaceholder.typicode.com/posts/1，Body 选 raw + JSON 填上改好的完整内容，Send → 状态 200
DELETE：方法选 DELETE，同一 URL，不填 Body，Send → 状态 200

DELETE 的响应你会看到：

{}

「删已办结，给你个空包裹作证」——练习接口就这性格。注意 PUT 面向的是「整件替换」，所以发送时要给改完后的完整内容。

记忆口诀：查寄改拆（GET/POST/PUT/DELETE）；POST 带 JSON 走 raw；400 你错、401 没凭证、404 找不到、500 后端慌。

3.6 动手改

POST 一篇不带 userId 的文章，观察服务器照样回什么（体会假服务的宽容）
把 title 的值改成数字 12345 再 POST 一次，对比两次响应的差异
用 PUT 把 posts/1 的 title 改成你自己编的一句话，再用 GET 打同一个地址，确认改动「生效」

3.7 小结

四方法：GET 查、POST 寄、PUT 整换、DELETE 拆
请求体：Body → raw → JSON；Content-Type 这时由 Postman 自动补
六状态码：200/201 好事，400/401/404 你的锅，500 服务器的锅

下一章：集合与环境变量 🐸