手搓 API 之前
先把 HTTP 看明白

调用 API 时我们站在客户端，这一次要换到服务端——做一个等在被调用方的程序。而被调用方必须遵守的规矩，正是 HTTP。

导读

      一次 HTTP 对话，就是一去一回两段有固定格式的纯文本。请求和响应的结构基本对称，理解这几行文本，就理解了 API 的本质。
    

本课目标：不依赖框架，用 Python 标准库手写一个返回 JSON 的 API，并且完成两个能加深印象的小实验。

一次 HTTP 对话的完整结构

→ 请求（Request）

请求行
请求头
空行
请求体（GET 常省略）

← 响应（Response）

状态行
响应头
空行
响应体

      请求第一行是请求行，响应第一行是状态行，二者有唯一的结构差异。其余三部分一一对应，格式统一。
    

请求行的三要素

请求行用一句话说明三件事：

方法	我来干嘛的？（GET / POST / PUT …）
路径	要访问哪个资源？
协议版本	HTTP/1.1 或 HTTP/2 等

例：GET /api/ip HTTP/1.1

HTTP 方法与状态码

常用方法 · 直观理解

方法	含义
GET	“把某样东西给我”，通常不带请求体
POST	“我提交内容请你处理”，内容放请求体
PUT	用我给的，把整个换掉
PATCH	把某一部分改掉
DELETE	删掉
HEAD	同 GET，但不要响应体
OPTIONS	“我能对这个资源做什么？”

状态码规律

2xx

成功

4xx

请求方的问题

5xx

服务方的问题

状态码不用背，记住规律即可。

一个经典误区

      GET 不是“往回调数据”，POST 也不是“往外发数据”。

      HTTP 描述的不是数据流向，而是请求的意图：

      GET = 把某样东西给我；

      POST = 我提交一段内容，请你处理。

请求头 & 响应头 · 常见项

常用请求头（客户端 → 服务端）

Host 要找哪台机器 User-Agent 我是谁
Accept 我要什么格式 Accept-Language 语言偏好
Content-Type 请求体格式 Content-Length 请求体长度
Authorization 身份凭证 Cookie 随身小纸条

常用响应头（服务端 → 客户端）

Content-Type 响应体格式（实践必写）
Server 服务器软件 Set-Cookie 发小纸条
Location 重定向到哪 Cache-Control 缓存策略
Access-Control-Allow-Origin 允许谁跨域调用

编写 API 时必须处理的「四件事」

读请求行——分清方法和路径，否则无法决定返回什么
写状态行——状态码是响应的底线，缺失即报错
写空行——头和体之间的分界线，漏了会乱套
写 Content-Type——规范不强制，但实践不可缺

请求头按需读取即可；响应体才是 API 的主角。

用 Python 手写 API · 核心代码解析

class Handler(BaseHTTPRequestHandler): def do_GET(self): if self.path == "/": self.send_response(200) self.send_header("Content-Type", "application/json; charset=utf-8") self.end_headers() self.wfile.write(json.dumps({...}).encode()) else: self.send_response(404) self.end_headers() # ··· 启动服务，监听 8000 端口

do_GET 处理 GET 请求
send_response(200) 状态码
send_header Content-Type
end_headers 输出空行
self.path 判断路径
404 兜底

      端口为什么是 8000？没有特殊规定。避开 80、443、22 等常用默认端口，挑一个空闲的就行。8000 是 Python 圈子的习惯值。
    

实验一 · Content-Type 的重要

同样一段内容，在不同的 Content-Type 下浏览器展示效果不同：

text/html

浏览器按网页渲染

application/json

按 JSON 数据解析

      不指定字符集时还会发生乱码。建议写 Content-Type: application/json; charset=utf-8。
    

浏览器眼里网页和 API 没有本质区别——都是 HTTP 请求+响应，只是返回的格式不同而已。

实验二 · 服务端能看清来访者

打开浏览器开发者工具 F12 → Network → Headers，可以看见：

User-Agent——一眼认出是浏览器还是 curl
客户端 IP——本地请求显示 127.0.0.1
请求头——浏览器 vs curl 发出的完全不同

      这些元信息的用途很广：统计来源地区、识别浏览器、做防刷限流、国际化多语言等。当然，也可以伪装 User-Agent——HTTP 就是如此单纯。
    

为什么要先手搓？

一个 GET 接口，需要处理路径判断、状态码、响应头、空行、响应体……真实的项目有几十上百个接口，人人都在重复同样的 HTTP 杂活。

于是有人把这套底层工作打包成了框架——下一节 FastAPI 登场时，手写的十几行代码会浓缩成几行。

先手搓，是为了理解框架到底帮我们做了什么。

“孤勇之后，世界近在眼前。”
—— 学完这节课，再看 HTTP 请求，你就能真正看懂了。

手搓 API 之前先把 HTTP 看明白

手搓 API 之前
先把 HTTP 看明白

手搓 API 之前，先把 HTTP 看明白