A Window, a Q&A: API
第四篇结尾说：下一篇，换一个新问题——两个完全不同的程序之间，怎么互相说话？
先从一个日常谜团说起。你手机里的天气 App，怎么知道明天下不下雨？它自己没有气象站，没有雷达，也没有一个员工在夜观天象。答案是：它在问另一台电脑。
这一篇就讲清楚：这种“程序问程序”的机制，是怎么运转的。
一
天气 App 和背后的天气服务器，是两个完全不同的程序：不同公司开发，用的可能是不同的编程语言，跑在不同的机器上。它们凭什么能合作？
你可能会想：连上网络不就能说话了吗？——但“连得上”只是物理上通了，就像你和一家餐厅隔壁而居，不代表你们能交易。交易之前，得先有个约定：
- 你怎么问：问什么、按什么格式问；
- 我怎么答：答什么、按什么格式答。
天气 App 和天气服务器之间，就提前签了这样一份约定：“你按这个格式来问 weather（天气），我就按那个格式把数据回给你。”问的叫请求，答的叫响应——第一篇的老朋友了。
这种“程序和程序之间提前约好的说话规矩”，就叫：API（Application Programming Interface，应用程序编程接口）。
名字的三个单词都很吓人，翻译成人话就一句：给程序用的接口。接口就是“窗口”：餐厅的后厨你进不去，但点菜窗口对所有人开放。你不需要懂后厨怎么炒菜，你只需要知道——窗口在哪、怎么递单子、菜会从哪里出来。
其实一家服务经常两个窗口都开：网页版给人看，API 给程序用。同一个天气服务，你在浏览器里看到的是漂亮的页面，App 拿到的是一串数据——两个窗口，一个后厨。
二
那么，“问”到底长什么样？
第一篇拆网址的时候埋过伏笔：协议、域名、端口、路径、查询参数。现在要兑现了。API 的“问”，通常就是一个网址：
https://api.example.com/v1/weather?city=nanjing一段一段看，全是熟人：
api.example.com：找哪台服务器（域名，第一篇）；/v1/weather：要什么东西——不是“给我网页”，而是“给我天气”；?city=nanjing：附带条件——哪个城市的天气。
是的，**调用一个 API，绝大多数时候就是访问一个网址。**把 city=nanjing 改成 city=shanghai，回来的就是另一座城市的天气——同一个窗口，换一种问法，换一个答案。
如果有多个条件，用 & 连起来（& 就是“和”）：?city=nanjing&days=3——问南京未来三天的天气。
三
“问”是网址，那“答”呢？
第一篇说过：浏览器收到 HTML，渲染成画面给你看。但 App 不要画面——画面是给人看的，程序要的是数据。所以程序之间的“答”，通常用另一种格式：JSON。
它长这样：
{
"city": "南京",
"temperature": 24.5,
"weather": "多云"
}看着乱，其实就是一张“标签 + 值”的清单：冒号左边是“这是什么”，右边是“具体是多少”，逗号隔开一条条，最外圈用花括号包起来。程序拿到它，就知道去哪个标签下取哪个值——temperature 标签下面，取 24.5。
另外，第一篇讲过的状态码，在这里原样适用：每次响应都挂着那个三位数的体检报告。200 是拿到了，404 是“你问的这个东西不存在”，500 是“答话的一方自己出错了”。程序和人一样，先看体检报告，再读内容。
四
现在你可以亲手调一次 API。不需要装任何东西——还记得吗，调用 API 就是访问网址，所以浏览器就够了。
在地址栏粘贴这个（一个不需要钥匙的免费天气服务）：
https://api.open-meteo.com/v1/forecast?latitude=32.06&longitude=118.78¤t_weather=true回车，屏幕上出现一坨 JSON——南京此刻的天气。看不懂没关系，找到里面的 temperature 标签，它下面的数字就是气温。
然后把 latitude=32.06&longitude=118.78 换成 latitude=39.9&longitude=116.4（北京的坐标），再回车——同一扇窗口，换了个问题，答案就换了一座城市。
再进一步：按 F12 打开 Network 面板刷新页面，你能看到这整个“请求 → 响应”的过程——和第一篇看普通网页时一模一样。对浏览器来说，这两件事从头到尾就没有区别。
五
有一个东西必须单独讲：API key（钥匙）。
上面那个天气服务，谁都能白嫖。但很多 API 不是：用之前要先注册，领到一串乱码一样的字符，每次请求都要带上它——相当于在窗口递单子时，先出示会员卡。为什么要有这道手续？三个原因：
- 认人：知道是谁在问；
- 限量：免费额度用完要收费，不然服务器会被问爆；
- 记账：谁问了多少次，得算得清。
然后是新手最容易踩的那个大坑，务必记住：API key 等于密码，而且是一张能花钱的密码。
vibe coding 时代，这个事故的剧本高度一致：让 AI 写了个调用某服务的程序，AI 把钥匙直接写在了代码里，然后你随手 git push 到了 GitHub 的公开仓库——GitHub 上有爬虫全天候地扫公开仓库里的钥匙，扫到就立刻拿去刷你的额度。等你发现时，账单已经产生了。
还记得第四篇说的吗：Git 会记住历史的每一版。所以把文件删掉重传是没用的，钥匙还在历史里躺着。正确做法是让钥匙待在代码外面——具体怎么放，以后你问一句“API key 应该怎么安全存放”，AI 会给你方案。你要做的，是知道这件事的分量。
六
最后把 AI 放进来。
以后你最常对 AI 说的话里，一定有一句是：“帮我接一个 XX 的 API。”这件事 AI 非常擅长：它读服务的文档（文档里翻来覆去就两件事：怎么问、怎么答），然后写出请求的代码，处理好返回的 JSON。
而你的工作是三件：把文档或网址给它；跑起来验收结果对不对；出错的时候，把报错原样贴回给它——第三篇的老规矩。
你甚至不需要自己读懂文档。但这一篇希望你带走的是一种眼光：再复杂的服务，你和它之间也就一扇窗口、一次问答。
七
回头看：天气 App 不懂气象学，它只是找到了那扇窗口。这就是这一篇想留给你的：
不一定要理解整个系统，先找到和它交互的接口。
生活里到处是这个思维：你用电，不需要懂电网，只需要懂插座；你点外卖，不需要懂后厨，只需要懂下单的那个按钮。面对一个庞大复杂的东西，先别被“我全都搞不懂”吓退，先问：我和它之间的窗口在哪？它收什么、给什么？——问题一下子就小了。