安全幂等
起始行（请求行）
GET /users/42 HTTP/1.1头部 headers
Host: api.example.comAccept: application/json空行（CRLF）
主体 body（无主体）
数据与服务 · 网络与接口
网页通信协议HTTP
HTTP 是 Web 上客户端与服务器交换信息的协议：一次通信 = 请求消息 + 响应消息，每条消息都是「起始行 + 头部 + 空行 + 可选主体」，协议本身无状态。
拆解一次 HTTP 交换：请求 + 响应
HTTP 把一次通信组织成两条消息——客户端发请求消息，服务器回响应消息。每条消息都是「起始行 + 头部 + 空行 + 可选主体」。选方法和状态码，点发送，看抓包格式里各部位怎么变。
方法
响应状态码
⏳
点「发送请求」把上面这条请求交给服务器，响应消息会按抓包格式在这里展开。
无状态：HTTP 协议本身不记得上一次请求；要把多次请求串成会话，得靠Cookie / Authorization 头。
选好方法和响应状态码，点「发送请求」把这条请求交给服务器；下一步在响应消息里读状态行、头部与主体。
消息骨架与零件索引
面板里反复出现的四个部位就是 HTTP 消息的全部结构；想深入某一部位，进对应的零件卡。
方法说明意图（读、写、改、删），路径定位资源，版本声明协议。请求的生命周期、取消与重试详见 request。
状态码告诉客户端结果类别。状态码如何映射到客户端动作详见 status-code；data/error 响应契约详见 response。
Content-Type、Cache-Control、Authorization 等都在这里。头部字段语义与安全风险详见 http-headers。
GET/DELETE 常无主体；POST/PUT 用主体承载 JSON、表单或文件。主体格式由头部的 Content-Type 声明。
什么时候用 HTTP，什么时候要换协议
HTTP 适合「客户端发起、请求—响应、可缓存」的通信；不是所有场景都该用它。
页面、接口、文件下载这类「客户端主动问、服务器答、可缓存可代理」的场景。跑在 TCP 上（HTTP/1.1、HTTP/2 多路复用；HTTP/3 跑 QUIC/UDP）。
任何涉及登录、支付、个人数据的链路。HTTPS 就是 HTTP over TLS，语义相同，只多了加密、完整性与身份认证。
服务器主动推送、双向实时、长连接选 WebSocket；消息队列、RPC 等场景有专属协议。别把 HTTP 当万能锤。
怎么用：选对方法，读对状态码
从「我要对资源做什么」走到「服务器告诉我什么」的最短路径。
- 定意图：读用 GET、新建用 POST、整体替换用 PUT、删除用 DELETE；不要用 GET 改数据。
- 组消息：写操作带 Content-Type 和主体；鉴权、缓存、内容协商等元信息放头部。
- 读状态行：先看 2xx / 3xx / 4xx / 5xx 类别，再看具体码和原因短语。
- 按类别行动：2xx 取结果，3xx 跟随或用缓存，4xx 让用户修正，5xx 谨重重试。
用 HTTP 时要盯这些：方法是否匹配意图（读用 GET、写用 POST/PUT）、状态码是否说真话（失败不能返 200）、主体格式是否与 Content-Type 一致、敏感信息是否只在 HTTPS 头部里传输。
正反例：语义化方法 + 诚实状态码
同一个「删除用户 42」的目标，正例让协议自解释，反例把语义藏进主体里猜。
DELETE /users/42 HTTP/1.1HTTP/1.1 204 No ContentDELETE 明确表达删除意图且幂等；204 说明已删除、无主体返回。重发安全，代理和缓存能正确处理。
POST /users/42/delete HTTP/1.1HTTP/1.1 200 OK{ "ok": false, "err": "not_found" }方法不表达意图、不幂等；失败也用 200，客户端只能解析主体猜成败，缓存和重试逻辑全部失效。
快速自测
客户端要「整体更新用户 42 的资料」并让重复提交不产生额外副作用，方法与状态码应怎样配合？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。