第 4 章 API：软件之间的握手

软件不光和人打交道，更多时候是软件和软件打交道。它们之间的"服务窗口"，就叫 API（Application Programming Interface，应用程序接口）。

用银行来想：金库（数据库）你不能进，你只能到柜台窗口（API），按规定格式填单子，办理规定范围内的业务。天气 App 显示的温度，是它去调了气象服务的 API；我们的网站给用户发邮件，是去调了 Resend 的 API；查一笔链上交易，是去调了区块链节点的 API。现代软件的真相是：把十几个别人的 API 粘在一起，再加上你自己独有的那一点逻辑。

窗口的地址和规矩，有一套最流行的风格叫 REST：URL 是名词，表示"哪种东西"，比如 /certificates/123 指编号 123 的那张凭证；HTTP 方法是动词，表示"想干什么"——GET 是读，POST 是新建，PATCH 是修改，DELETE 是删除。一个具体的地址（比如 GET /certificates/123）叫一个端点（Endpoint）。

软件之间传的"单子"，用一种通用格式写，叫 JSON。长这样：

{ "name": "Charles", "age": 12, "projects": ["EchoForge", "ForgeCard"] }

就是"名字：值"的组合，人能看懂，机器也能看懂。你在日志里、报错里、AI 的输出里会天天见到它。

最后是API Key：柜台发给你的通行证。它证明"是我在办业务"，服务商也靠它记账、限流。所以它是秘密——拿到你 key 的人，就能冒充你、花你的钱。怎么保管它，第 9 章专门讲。

关键领悟

会读 API 文档（或者让 AI 读给你听），等于拥有了全世界的乐高积木。

试一试

让 AI 列出我们某个项目实际调用了哪些外部 API，各自负责什么——你会发现"粘乐高"这个说法一点不夸张。