波仔
🕸️ 第一章 Web技术基础知识
📄 一句话概括

浏览器不是访问 Web 的唯一入口——程序之间也可以直接对话，这套对话的规矩叫 API。它的意义在于把"给人看的页面"和"给程序用的数据"分开，于是同一份内容，能被 Apps、脚本、别的系统各取所需。

📝 本节和前面几节的关系

1-3 提到"专用应用程序"是绕过浏览器的另一条路，当时只说了它省流量。这一篇就把那条路正式命名并展开——它叫 API。前面几篇讲的一直是"浏览器怎么取、怎么画"，这一篇要说明的是：Web 这套技术不只是给浏览器用的，它已经变成程序之间通用的接线方式。

一、谁来跟服务器讲话

先把"用户"这件事拆开——跟服务器说话的，未必都是人：

这两种需求长得很不一样。人需要排版、需要按钮；程序只需要数据，它自己知道怎么展示。如果让程序去下载一整个网页、再从里面挑出需要的那几个数字，那是巨大的浪费。 API 就是为解决这个浪费而生的。

二、API 这个词到底指什么

API 的全称是"应用程序编程接口"。中文里听着绕，其实就一句话：它是一份约定——你按这个格式问，我就按这个格式答。

用一个生活里的比喻：去餐厅点菜。

所以 API 的价值不在"能连上"，而在"双方约定好了怎么说话，于是可以各管各的"：服务器随便改内部实现，只要菜单没变，调它的程序就不用跟着改。

三、今天最常用的几种"说话风格"

API 不是只有一种写法。教材成书时最常见的对比是"页面 vs API"，今天已经细化成好几种风格，各有各的适用场景：

风格 一句话 适合
REST 用网址表示"要什么"，用动词表示"做什么" 对外开放的接口，最普及
WebSocket 一次连上、双向keep着，随时能互相推 聊天、实时协作
GraphQL 由调用方说"我要这几个字段"，只给这些 前端复杂、字段多变
gRPC 二进制、快，适合服务之间内部通信 自己系统内部
Webhook 反过来——有事我通知你，不用你一直问 事件通知

其中 REST 是绝对主流。理解它有一句口诀：网址是名词（要哪个东西），动词在动作里（是要、是改、是删）。比如"看第 42 号商品"和"下单"，网址不同、动作也不同。

四、动手 Demo：页面和 API，拿回的东西差多少

下面这个 Demo 拿一次的对比算给你看：同样一件事，用浏览器打开页面和用程序调 API，拿回的数据量差多少；顺带把今天各种 API 风格的采用率列出来。

page = 1.2 * 1024   # KB，整个页面的资源
api = 2.0           # KB，一段 JSON
print("页面 %.0f KB，API 约 %.0f KB，差 %.0f 倍" % (page, api, page / api))

实跑输出：

--------------------------------------------------------------------
D7  独立于浏览器之外的 Web 连接机制：API
--------------------------------------------------------------------
  同样是【跟服务器讲话】，页面和 API 是两套说法：
  ----------------------------------------------------------------------------------------
  方式                  要什么                        拿回什么
  ----------------------------------------------------------------------------------------
  浏览器打开页面        一整个网址                    HTML+CSS+图片，1.2 MB
  程序调用 API          一个接口名加参数              一段 JSON，约 2 KB

  同样一件事，API 拿回的数据量只有网页的 1/614。
  这正是 API 存在的理由：浏览器是给人看的，API 是给程序用的。

  今天程序之间说话，主要用这几种风格（Postman 2025，受访团队采用率）：
  ----------------------------------------------------------------------------------------
  风格                采用率      特点
  ----------------------------------------------------------------------------------------
  REST                93%         最普及，用网址加动词表达，缓存方便
  Webhooks            50%         由服务反过来通知你，不用轮询
  WebSockets          35%         长连接，双向，聊天和实时必备
  GraphQL             33%         客户端说要哪些字段，只给这些
  SOAP                25%         老一代企业级，规矩重、仍有人用
  gRPC                14%         二进制协议，内部服务之间最快
  Server-Sent Events  12%         服务器单向推消息给浏览器

  注意几十个百分点的合计超过 100%：一个团队往往同时用好几种，
  最常见的是【对外 REST、对内 gRPC、要实时就加 WebSocket】。

读这个输出：1/614 这个比例说明 API 为什么快——它只拿数据，不拿"怎么显示"。而下面那张表最该记住的是最后一句：风格不是选边站，是分场合用。对外要让人看得懂、方便调试，用 REST；自己系统内部要快，用 gRPC；要实时，加 WebSocket。一个团队同时用好几种是常态，不是混乱。

五、⚠️ 2026 现状

教材 2024 年出版，"页面 vs API"这个大框架没变，但有三处明显的新趋势：

30 秒实验

不用写代码，用浏览器就能看一眼 API 长什么样：

  1. 在地址栏里打开一个公开的接口地址（很多网站提供这类示例地址，形如 https://.../api/...）。
  2. 你会看到页面上没有排版、没有图片，只有一段花括号包起来的数据——那就是 API 的"回应"。
  3. 对比一下刚才那个网站的首页：同样来自一台服务器，一个给人看，一个给程序看。

然后想一想：你手机里那些 App，是不是都在悄悄地调这种接口？

常见误区

  1. 错误：API 就是网页的另一个地址。——纠正：它是另一套"说话方式"，不是另一个网址。网页返回的是"给人看的整页"，API 返回的是"给程序用的数据"。同一个服务器可以同时提供这两种——你在浏览器里看到首页，App 里看到的是同一台服务器回的接口数据。

  2. 错误：API 只给外部开发者用。——纠正：一个系统的内部也是靠 API 拼起来的。今天的大系统常被拆成很多小服务，它们之间就是互相调 API。所以 API 不是"对外开放的窗口"，更是"内部沟通的语言"。

  3. 错误：用了 API 就更快更省，所以能上就上。——纠正：风格要配场合。对外开放的接口用 REST 最省心（好懂、好调试、能缓存）；自己内部要极致性能才考虑 gRPC。盲目追新用一套复杂方案去解决简单问题，是常见的浪费——这也是那张采用率表里 REST 依然 93% 的原因。

  4. 错误：接口一旦发布就随便改，反正没人管。——纠正：API 是"菜单"，改了菜单别人点菜就出问题。所以正规做法是保留旧版本、新增而不是替换。这不是技术洁癖，是因为调你接口的可能是一堆你根本不认识的人（甚至包括 AI）。

自测三问（点开对答案） 1. 为什么说 API 让"服务器和调用方可以各管各的"？ —— 因为 **API 是一份约定，约定之外的东西可以随便改**。只要菜单上的菜名和上菜格式不变，厨房怎么装修、换什么灶，点菜的人都不用管。**这正是它能支撑"很多团队独立开发"的原因**——大家只认约定，不认内部实现。 2. 网页和 API 都是从那台服务器来的，为什么一个大一个小（1.2 MB 对 2 KB）？ —— 因为**网页多带了"怎么显示"这一整套东西**：样式、脚本、图片，它们的目的都是让人看得舒服。而 API 只回**数据本身**，显示的事交给调用方。**所以省下来的不是"内容"，是"包装"**——这也正是 1-3 里 App 比网页快的原因。 3. 为什么"对外 REST、对内 gRPC"会成为常见搭配？ —— 因为**两边的受众不同**。对外的调用方是不认识的人和第三方，要的是**好懂、好调试、能缓存**；系统内部是自家服务之间通信，要的是**快和体积小**。**同一件事在两个场合下最优解不同**——这不是互相矛盾，是分工。

相关笔记