多半是请求这一半出了问题：方法不对、Content-Type 与体不匹配、缺 Host 或空行。先看请求行和头再找服务端原因。
把方法、路径、头和体拼成一条请求
一条 HTTP 请求是一段可读文本：请求行说明意图和目标，请求头携带元信息，空行分隔头与体，请求体承载提交数据。改方法或路径，请求行第 1 行立刻不同；GET / DELETE 一般不携带请求体。
方法（请求行第 1 段）
请求头（每行 名: 值）
提交的数据走请求体；记得让 Content-Type 与格式匹配。
请求消息预览待构造
POST /api/favorites HTTP/1.1Host: …填好左侧参数，点「构造请求」展开完整消息。尚未构造。选好方法、路径、请求头与请求体，点「构造请求」把消息像抓包一样展开。
请求消息的四段从哪读出来
实验台里每一段都对应请求文本的一个区域；下面给它们命名，并补充面板里看不见的两点。
- 请求行：方法 + 请求目标 + HTTP 版本，是消息的第 1 行。方法说「想干什么」（GET 取、POST 提交、PUT/PATCH 改、DELETE 删），请求目标说「对哪个资源」。
- 请求头：每行一个 名: 值。Host 是必填项；Accept 表达想要的格式，Content-Type 声明请求体格式，Authorization 带凭据，Cookie 带会话。
- 空行：告诉服务端「头结束了，后面如果有内容就是体」；它不是装饰，缺了会解析错位。
- 请求体：可选。POST/PUT 把提交数据放在这里（JSON、表单或 multipart）；GET 的参数走查询字符串，一般没有体。
- 方法语义（补充）：GET 安全且幂等、PUT/DELETE 幂等、POST 不幂等——这决定能否重试、会不会重复写入。
什么时候要看请求这一半
当你设计或调试接口、读网络面板、或纠结某个字段放哪时，先把请求拆成这四段。
公开条件走查询参数，提交数据走请求体，凭据走 Authorization 头，会话走 Cookie。放错位置会带来缓存串号、日志泄密或重复写入。
从意图到一条可发送的请求
最短路径是：选方法 → 把资源放进路径 → 元信息进头 → 提交数据进体 → 核对 Content-Type 与体一致。
- 选方法：读取用 GET，提交新建用 POST，整体更新用 PUT，删除用 DELETE。
- 定位资源：路径指向资源（/api/favorites），筛选与翻页拼成查询参数（?limit=20）。
- 补元信息：Host 必填；需要时加 Accept、Authorization、Cookie。
- 带提交数据：POST/PUT 把数据写进请求体，并让 Content-Type 与格式匹配。
- 核对：用网络面板看真实请求文本，确认四段层次清楚、敏感数据不在 URL。
同一目标，只改一处关键选择
每条按钮把配置载入上方实验台；点「构造请求」看结论长在请求消息物件上。
POST /api/favorites，Content-Type: application/json，JSON 请求体，token 在 Authorization 头。服务端能稳定解析，URL 不留凭据。
服务端不知道请求体是 JSON 还是表单，可能拒绝或按错格式解析，错误难以定位。
GET /api/favorites?token=… 会把凭据写进 URL，被访问日志、浏览器历史和 Referer 头留存，泄露面比请求头大得多。
快速自测
提交一段 JSON 创建评论，下面哪种请求结构最合理？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。