模块 5.3 · 后端第三课

看懂 HTTP，手搓 API

理解 HTTP，用 Python 手搓一个属于自己的 API

零到全栈 · 李勃老师 · 2026

「调用 API」里藏着两个角色

一方发起请求，一方给出回应

💻

调用方

发起请求

请求 request▶

HTTP

◀响应 response

🗄️

被调用方

给出回应

这一来一回，双方到底传的是什么？——两样东西都归一套规范管，它就是 HTTP。

1

这一节真正的主角

HTTP

再简单的 API，也得按 HTTP 的规矩来设计

今天这一节

先看懂规范，再动手实现

1看懂 HTTP 的一去一回：请求、响应各长什么样

2用 curl -v 把真实报文调出来，亲眼验证

3用 http.server 手搓一个 API（GET /api/profile）

4两个小实验，把 HTTP 和 API 玩明白

回看前两节的三次调用

过去我们都在「调用方」这一边

调用方（我们）

被调用方（对方的服务）

💻 终端 curl

HTTP

ipify

💻 终端 curl

HTTP

DeepSeek

🐍 python 脚本

HTTP

ipify

这一节，我们要走到右边去——自己做那个「被调用方」。

123

HTTP 的一去一回

两段有固定格式的纯文本

💻

调用方

请求 request 的四个部分

请求行方法 GET / POST · 路径 · 协议版本GET /api/health HTTP/2

请求头若干条附加说明，一行一条 名字: 值User-Agent: curl/8.7.1

空行头说完了，下面开始是体

请求体真正要提交的内容——可以没有

请求 request▶

◀响应 response

响应 response 的四个部分

状态行状态码：2xx 成功 · 4xx 请求方问题 · 5xx 服务方问题HTTP/1.0 200 OK

响应头最重要的是 Content-Type——内容是什么格式Content-Type: application/json

空行跟请求一样，是分界线

响应体正文，我们平时「看到」的就是它

🗄️

被调用方

结构几乎对称，唯一区别在第一行：请求叫请求行，响应叫状态行。

12

关于方法 · 一个常见的误会

方法描述的是「意图」，不是「数据往哪边流」

✗ 容易这么以为

GET 是「往回拿数据」、POST 是「往外送数据」——那调 DeepSeek 又送又拿，岂不是「又 POST 又 GET」？

GET

「把某样东西给我」

通常不带请求体

POST

「我提交一段内容，请你处理」

内容就放在请求体里

所以调 DeepSeek 就是一次 POST——它回来的那段 JSON，是这次 POST 的响应，不是另一次 GET。

认个脸 · 常见的方法

方法，就是几种常见的「意图」

GET	把某样东西给我
POST	我提交一段内容，请你处理
PUT	用我给的内容，把某样东西整个换掉
PATCH	把某样东西改一部分
DELETE	把某样东西删掉
HEAD	跟 GET 一样，但只要头、不要体——探路用
OPTIONS	问一句：我能对这个资源做什么？（前后端联调时会再见到）

不用记，扫一眼建立直觉——以后在真实报文里撞见，能大概猜到它在说什么。

认个脸 · 常见的头

头，就是一行一条的「附加说明」

常见请求头 · 调用方对自己这条请求的描述

Host	我找哪台机器
User-Agent	我是谁（什么工具 / 浏览器）
Accept	我要什么格式
Accept-Language	我偏好什么语言
Content-Type	我提交的体是什么格式
Content-Length	我提交的体有多长
Authorization	身份凭证（`Bearer sk-…`）
Cookie	随身带的「小纸条」

常见响应头 · 服务方对响应内容的交代

Content-Type	我回的是什么格式（本节主角）
Content-Length	有多长
Server	我是什么服务器软件
Date	什么时间处理的
Cache-Control	能不能缓存
Set-Cookie	发一张「小纸条」给调用方
Location	内容搬家了，去新地址找
Access-Control- Allow-Origin	允许哪些来源的网页调用我

这还不是完整清单。见到不认识的头，一般可以不用管——就像刚才 ipify 那个 cf-ray。

12

换个视角 · 站在服务方这一边

哪些是必须处理的？

💻

调用方

收到请求 · 必须会「读」

✓请求行 GET/POST /path HTTP/2来取数据还是来提交，要哪个资源

○请求头可读可不读，用到哪条读哪条

○空行分界线，Python 替我们认好了

○请求体GET 通常没有；POST 才要自己读

请求 request▶

◀响应 response

给出响应 · 必须会「写」

✓状态行不回状态码，就不算一段 HTTP 响应

!响应头 Content-Type规范可省，实践当必写

✓空行头和体的分界线，漏了就乱套

✓响应体真正要给对方的内容——主角

🗄️

服务方

端口：8000

http.server

这是 HTTP 的要求，不是某个工具的要求——换语言、换框架，也照样得有人写。

12

后端之旅 · 下一步

孤勇之后
世界尽在眼前

下一节，FastAPI 登场——这一节亲手写下的杂活，会缩成几行。咱们下一节见。