HTTP 请求和响应的基本结构

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

HTTP 请求（HTTP Request）是客户端（如浏览器、App、Postman）向服务器发起通信的标准格式。它遵循 HTTP 协议规范，架构明确、文本可读。

HTTP 请求的基本框架

一个完整的 HTTP 请求由三部分组成：

请求行（Request Line）
请求头（Headers）
空行（\r\n）
请求体（Body，可选）

1. 请求行（Request Line）
   格式：
   

   <方法> <请求URI> <HTTP版本>

   
   示例：
   

   GET /api/users/123 HTTP/1.1
   POST /login HTTP/1.1
   PUT /renewable/update HTTP/2

   
   方法（Method）：如
   

   GET

   、
   

   POST

   、
   

   PUT

   、
   

   DELETE

   、
   

   PATCH

   等
   请求 URI：资源路径，不含域名（完整 URL 在 Host 头中体现）
   HTTP 版本：通常是
   

   HTTP/1.1

   或
   

   HTTP/2

2. 请求头（Headers）
   格式：
   

   字段名: 值

   
   每行一个，用于传递元信息。
   常见请求头示例：
   

   Host: api.example.com
   User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
   Accept: application/json
   Content-Type: application/json
   Authorization: Bearer abc123xyz
   Content-Length: 45

   
   作用包括：告知服务器客户端能接受的格式（
   

   Accept

   ）声明请求体的类型（
   

   Content-Type

   ），身份认证（
   

   Authorization

   ），指定目标主机（
   

   Host

   ，在虚拟主机中必需）
3. 空行（Empty Line）
   用一个换行符
   

   \r\n

   
   表示头部结束。是请求头和请求体之间的分隔符。
   必须存在，即使没有请求体。
4. 请求体（Body，可选）
   只有在
   

   POST

   、
   

   PUT

   、
   

   PATCH

   等方法中才可能有。
   内容由
   

   Content-Type

   决定，常见类型：
   

   application/json

   → JSON 数据
   

   application/x-www-form-urlencoded

   → 表单键值对
   

   multipart/form-data

   → 文件上传
   

   text/plain

   → 纯文本
   示例（JSON Body）：
   

   {
     "username": "alice",
     "password": "123456"
   }

完整请求示例：

POST /login HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 45
Accept: application/json

{"username":"alice","password":"123456"}

注意：最后一行之后通常还有一个

\r\n

，表示 body 结束（尤其在流式传输中重要）。

对比：HTTP 响应结构（补充）

请求（Request）	响应（Response）
第一行 GET /path HTTP/1.1	第一行 HTTP/1.1 200 OK
头部 请求头（Headers）	头部 响应头（Headers）
空行 \r\n	空行 \r\n
主体 请求体（可选）	主体 响应体（可选）

小知识：
GET 请求通常没有 Body（虽然 HTTP 协议未禁止，但语义上不合理，且许多服务器会忽略）。

Content-Length

或

Transfer-Encoding: chunked

用于标识 body 长度。
在 HTTPS 中，整个请求内容会被加密，但 DNS 和 SNI（Server Name Indication）仍可能暴露域名。

总结

HTTP 请求 =
请求行（方法 + 路径 + 版本）
请求头（元数据）
空行（分隔符）
请求体（可选，携带数据）
这是 Web 通信的基石，无论是前端调用 API、后端接收请求，还是测试工程师抓包分析，都离不开对这个结构的理解。
如果你需要，我也可以提供
用 curl 或 Postman 构造请求的例子

一、HTTP 响应的基本框架

一个标准的 HTTP 响应由三部分组成：

HTTP/1.1 200 OK                     ←── **状态行（Status Line）**
Content-Type: application/json      ←── **响应头（Headers）**
Content-Length: 123
...

[{"id":1,"name":"砖头块"}]          ←── **响应体（Body）**

1. 状态行（Status Line）
   格式：
   

   HTTP版本 状态码 状态文本

   
   例如：
   

   HTTP/1.1 200 OK

   、
   

   HTTP/1.1 404 Not Found

   
   状态码（如 200）和状态文本（如 "OK"）在这里，不在 Headers 中！
2. 响应头（Headers）
   是键值对，比如
   

   Content-Type

   、
   

   Cache-Control

   、
   

   Set-Cookie

   等。
   状态码不会出现在这里。
3. 响应体（Body）
   就是你看到的 JSON、HTML、XML 等实际数据。

二、

ResponseEntity

是怎么工作的？

当你写：

return ResponseEntity.ok(data);

Spring 会生成一个 HTTP 响应，其中：
状态行：

HTTP/1.1 200 OK

Headers：可能包含

Content-Type: application/json

Body：你的

data

序列化后的 JSON

所以：
状态码是通过 HTTP 协议的“状态行”返回的，不是放在 Header 里，也不是放在 Body 里。

常见误解纠正

误解	正确理解
“状态码在 Header 里”	状态码在 状态行，Header 是后面的键值对
“ ResponseEntity 把状态码放进 JSON 了”	它只控制 HTTP 状态行和 Headers，JSON 是 body，不包含状态码
“前端看不到状态码”	前端通过 fetch().status 或 axios.response.status 可以拿到状态码 例如，在 JavaScript 中： fetch('/renewable/type') .then(res => { console.log(res.status); // ← 这就是 HTTP 状态码（如 200） console.log(res.statusText); // ← "OK" return res.json(); }) .then(data => console.log(data)); // ← 这才是你返回的 JSON 数组

总结

问题	回答
状态码是否封装在 HTTP 请求头中？	不在请求头（Header），也不在请求中（这是响应！）。它在 HTTP 响应的状态行中。
ResponseEntity 是否包含状态码？	是的，它用来设置 HTTP 响应的状态码（如 200、404），但不会把它放进 JSON body。
前端如何获取状态码？	通过 HTTP 客户端（如 axios、fetch）的 response.status 字段获取， 不是从 JSON 里解析。

类比理解

可以将 HTTP 响应比作一个快递：

快递单号 + 配送状态（如“已签收”）→ 相当于 状态行（200 OK）

包裹上的标签（收件人、重量、保价等）→ 相当于 Headers

包裹里的东西 → 相当于 Body（你的 JSON 数据）

你不会把“已签收”写在包裹里面，也不会贴在标签上——它是在物流系统顶层的状态信息。

同样地，HTTP 状态码是传输层的状态，不是业务数据的一部分。

如果你希望同时使用 HTTP 状态码 + JSON 中的 code/msg（双重保障），也可以两者都用，但要明确分工：

HTTP 状态码：表示 协议层面的成功/失败（如网络错误、认证失败）

JSON 中的

code

：表示 业务逻辑的成功/失败（如“库存不足”）

这在复杂系统中是合理的，但需团队达成一致。

需要我帮你设计这样的混合方案吗？????

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：基本结构 HTTP ttp Application indication