什么是 API？看一个真实案例就懂

几乎每次 2026 年注册 AI 工具时，都会碰到同样的三个字母：API。ChatGPT、图像生成器、网页爬虫、CRM 集成——这个词无处不在，但大多数解释文章都还是从那个老掉牙的“餐厅比喻”讲起，最后也没真正让你看到 API 长什么样。这篇不一样。你往下看几节后，就会看到真实的 API 请求、真实的响应，也会明白为什么你的销售团队、运营流程和电商系统每天都离不开 API。

我在 花了很多时间琢磨，怎么把技术概念讲给业务团队听——也就是那些不写代码，但又必须懂工具之间如何协作的人。所以我查了大量资料，测试了真实的 API 调用，整理出这份指南，尽量给你那种“直接展示给我看”的体验，而不是只空讲概念。销售代表、营销经理、电商运营——这篇就是给你准备的。

什么是 API？用大白话说清楚

API（应用程序编程接口）是一组规则，让一个软件向另一个软件请求数据或动作，并拿回结构化的回答。

换句话说，它就是两个系统之间的官方接触点。你不会直接访问完整数据库、完整应用，或者它背后的整家公司。你访问的是 API 公开出来的那部分内容，按照它要求的格式来提问，然后拿回它承诺给你的结果。、 和 的定义都指向同一件事：API 是一种机制或契约，让软件组件按照既定规则和协议进行通信。

你可以把它想成得来速窗口。你按特定格式下单（某个套餐、规格，或者一些定制要求），然后拿回你要的东西——根本不用走进厨房。菜单就是 API 文档，窗口就是端点，收据就是响应。

不过，比喻只能帮你理解到某个程度。下面直接看一个 API 调用到底是什么样。

真实的 API 请求和响应长什么样

现在把这个 URL 复制到浏览器里：

1https://api.agify.io?name=michael

你刚刚向 Agify API 发送了一个 GET 请求，让它预测名字 “michael” 对应的年龄。返回结果会是这样（一个 JSON 响应）：

1{
2  "count": 304886,
3  "name": "michael",
4  "age": 61
5}

就是这样。你刚刚完成了一次 API 调用。没有代码，没有终端，没有安装任何东西。请求就是那个带参数的 URL，响应则是浏览器以文本形式展示出来的结构化数据。每个 API 的基本原理都一样：发出结构化请求，返回结构化响应。

API 不是什麼

API 不是数据库。它是数据库（或服务、模型）前面的受控访问层。

API 不是网站。网站是给人看的、给人点的；API 是给软件读和处理的——它返回的是结构化数据（通常是 JSON），不是视觉页面。

API 不是黑客行为。它只访问提供方明确开放出来的数据和操作。

为什么业务团队要关心 API？

如果你在销售、运营、营销或电商部门，你可能从来没有亲自写过 API 请求。但你其实一直在依赖连接了 API 的软件——而且理解这个概念，会让你在评估工具、设计自动化流程、和开发团队沟通时更占优势。

API 其实已经融入你的日常工作了——比如这些场景：

直接效果就是：更少的手动录入、更少的错误，以及那些原本要花几个小时的流程，现在几秒钟就能完成。 发现， 的受访者现在直接通过 API 创收，高于前一年的 28%。而且 的公司表示自己是“API-first”，也就是先设计和测试 API，再去构建依赖它们的应用。

下次你评估 SaaS 工具时，先问一个问题：它有没有 API？能开放什么能力？这一个问题，可能帮你省下好几个月的集成折腾。

API 是怎么工作的？请求-响应循环详解

模式永远差不多：

1. 你（客户端） 发送请求——“嘿，给我纽约的天气。”
2. API 接收请求，检查它是否有效、是否有权限，然后把它路由到正确的服务器。
3. 服务器 处理请求——查询数据库、运行模型，或者执行某个动作。
4. API 把响应送回去——带有答案的结构化数据（通常是 JSON），再加上一个状态码告诉你结果如何。

可以这样理解：

客户端 → 发送请求（方法 + 端点 + 请求头 + 请求体）→ API 端点 → 服务器 处理 → API 端点 → 发送响应（状态码 + JSON 响应体）→ 客户端

你真正会用到的关键术语

来源：、、。

模糊的请求会被拒绝。有效请求需要正确的端点、方法、权限和字段。好的 API 文档，就是告诉你能问什么、该怎么问的说明书。

API、SDK、Webhook、Library 有什么区别？

厂商演示很爱把 “API”、“SDK”、“webhook” 和 “library” 混着说，好像它们是同义词一样。其实根本不是。我听过太多这类介绍，深知这种混乱是真实存在的。下面这张表，就是我当年最希望别人直接递给我的那份区分说明：

再补充一点每个概念的背景：

• SDK：如果你在做移动应用，SDK 会把你需要的东西都给你——API、示例代码、文档、工具。除非你在和开发者打交道，否则你大概率不会直接接触 SDK。
• Library：library 是别人写好的代码，你可以放进自己的程序里用。它底层可能会调用 API，但它是给开发者用的工具，不是系统之间的通信通道。
• Webhook：不是你去问 API “更新有没有？现在有了吗？”，而是 webhook 反过来——事件发生时，服务器主动发通知给你。你可以把它理解成软件里的推送通知。

到了 2026 年，人们说 “API” 时，几乎总是指 Web API——更具体地说，就是 REST API。但了解这些相关术语，能让你在厂商推介会或和工程团队的 Slack 讨论里不至于一头雾水。

API 的主要类型，以及你会在什么时候遇到它们

按访问级别分类

• 公共（开放）API：任何人都能使用。例子：免费的天气 API，或者像 这样的公开数据 API。
• 私有（内部）API：只在公司内部使用，用来连接内部系统。例子：你的 CRM 和计费系统之间的通信。
• 合作伙伴 API：只在协议约定下，和特定业务伙伴共享。例子：物流公司把运输追踪数据共享给零售商。

按架构分类

来源：、、。

作为业务用户，你大多数时候会接触 REST API 和 webhook。其他类型了解一下就好，方便和供应商沟通；但对于 SaaS 文档、Zapier 集成，以及像 Thunderbit 这样的工具来说，REST 仍然是默认起点。

2026 年的 AI API：彻底改变场景的用例

老一套“什么是 API”的文章，总是默认每个人第一次接触 API 都是 Google 地图或 Stripe。到了 2026 年，这根本不现实。大多数新手第一次看到 “API” 这个词，往往是因为他们注册了 ChatGPT，试用了图像生成器，或者接触了某个 AI 爬虫工具。

从机制上看，AI API 和其他 API 没什么两样。你发出请求——提示词、文档、URL，都可以——再拿回结构化输出。不同之处在服务器端：它不是去查数据库某一行，而是去运行模型。

真实例子：

• OpenAI API：发送文本提示 → 返回 AI 生成的回答。
• 图像生成 API：发送描述 → 返回 AI 生成的图片。
• AI 数据提取 API：发送一个乱糟糟的网页 → 返回干净、结构化的数据。

Thunderbit 的开放 API 如何把杂乱网页变成结构化数据

现在进入我会带一点偏爱的部分（原因很明显）。 提供了一个开放 API，可以通过程序化方式使用 AI 驱动的数据提取能力：

• Distill API：发送网页 URL → 返回干净的 Markdown，便于分析或接入 AI 流程。非常适合内容分析、搭建知识库，或者把数据喂给 LLM 工作流。
• Extract API：先定义好数据结构（字段名、类型），再发送 URL → AI 会提取出符合你结构的 JSON 数据。

下面是一个简化示例。假设你把一个杂乱的 Amazon 商品页面 URL 发送给 Thunderbit 的 Extract API：

1POST https://api.thunderbit.com/v1/extract
2Authorization: Bearer YOUR_API_TOKEN
3Content-Type: application/json
4{
5  "url": "https://example-store.com/products",
6  "fields": [
7    { "name": "product_name", "type": "text" },
8    { "name": "price", "type": "number" },
9    { "name": "rating", "type": "number" }
10  ]
11}

返回结果会是：

1{
2  "status": "success",
3  "data": [
4    { "product_name": "Organic Cotton Tee", "price": 29.99, "rating": 4.7 },
5    { "product_name": "Linen Button Shirt", "price": 54.00, "rating": 4.5 }
6  ]
7}

这个响应可以直接拿去做表格。一次 API 调用，就替代了好几个小时的手动复制粘贴。 在无代码界面背后用的是同一套 AI 引擎，但 API 让需要规模化自动化的团队也能用起来。

如果你想进一步了解 AI 驱动提取在实践中怎么运作，可以看看我们的指南： 或 。

你的第一次 API 调用：动手小教程

两分钟。无需下载、无需安装、无需编码。准备好了吗？

第 1 步：打开浏览器

新建一个浏览器标签页。

第 2 步：粘贴一个免费的 API URL

把下面这个地址复制到地址栏，然后按回车：

1https://api.agify.io?name=michael

你刚刚向 Agify API 发送了一个 GET 请求，让它预测名字 “michael” 对应的年龄。

第 3 步：一起读懂 JSON 响应

你应该会看到类似这样的内容：

1{
2  "count": 304886,
3  "name": "michael",
4  "age": 61
5}

• "name" —— 你提供的输入
• "age" —— API 的预测结果
• "count" —— 它使用了多少数据点

就这样。你刚刚完成了一次 API 调用。

第 4 步：进阶——试试需要密钥认证的 API

现在试一个更接近真实业务场景的例子。去 ，注册一个免费账号，拿到 API 密钥。然后把下面这个 URL 粘贴进去（把 YOUR_KEY 替换掉）：

1https://api.openweathermap.org/data/2.5/weather?q=London&appid=YOUR_KEY&units=metric

这一次，你需要用 API 密钥证明你的身份。这就是认证——大多数真实世界的 API 都是这么工作的。

第 5 步：理解响应码

当你调用 API 时，有时拿到的不是数据，而是错误。下面是最常见的状态码含义：

来源：。

一张表看懂 API 安全：密钥、OAuth 和 JWT

你其实已经在不知不觉中用过两种认证方式：无认证（Agify）和 API 密钥（天气）。另外两种方法，把整个图景补完整了：

来源：、。

当你刚才粘贴 Agify 的 URL 时，你用的是无认证；当你加上天气 API 密钥时，你用的是 API 密钥认证。OAuth 和 JWT 则会在应用需要访问你的个人数据时登场——比如你点“使用 Google 登录”的时候。

Thunderbit 的 Chrome 扩展使用的是浏览器自身已经登录的会话（抓取时不需要单独的 API 密钥），而 Thunderbit 的开放 API 则使用标准的 Bearer 令牌认证。这就是一个产品里同时存在两种模型的实际例子。

如何安全保管 API 密钥

• 永远不要把 API 密钥公开出去（不要截图、不要共享文档、不要放到公开代码仓库）。
• 不要把密钥硬编码进共享文档或表格里。
• 如果你是开发者，使用环境变量或密钥管理器。
• 定期轮换密钥；一旦怀疑泄露，立即更换。

你每天都在用的真实 API 例子

你今天午饭前，可能已经用了六七个 API，却完全没注意到：

• 嵌入在商业网站里的 Google 地图：网站使用 Google 地图 API 来获取并显示地图。你看到的是地图；背后是 API 调用把它取了回来。来源：。
• “使用 Google/Facebook 登录”：基于 OAuth 的 API，让你不用新建账号就能登录。
• 支付处理（Stripe、PayPal）：你在线结账时，API 负责商家和支付平台之间的付款流程。来源：。
• 天气应用：你每次打开手机天气应用，它都会调用天气 API。
• AI 聊天机器人和助手：ChatGPT、Claude 以及 AI 爬虫工具，都是通过 API 对外提供能力。
• Spotify 的推荐引擎：当 Spotify 推荐歌单时，背后是 API 在提供曲目数据、用户偏好和模型预测。
• Thunderbit 的 AI 网页爬虫：使用 AI 从 ——现在还提供开放 API，方便团队大规模自动化数据提取。

怎么为你的业务需求选对 API

当你要选择一个 API——或者帮开发团队选——这些标准最值得问：

快速对比一下：

发现，企业平均要管理 ，其中 的企业管理的 API 至少有 500 个。规模这么大，文档、支持和清晰的定价就显得格外重要。

API 与自动化数据录入：这个概念开始变得实用了

当你把 API 用在业务流程里最枯燥的那一部分——数据录入——时，它就真正有意思了。

，而且——听起来不高，但如果你的数据集有 10,000 条记录，那就是 100 个错误。在金融、医疗或电商场景里，哪怕只是几个错误，也可能让交易泡汤，或者引发合规问题。

自动化数据录入系统把 API、OCR、AI 和机器学习结合起来，用于采集、提取、校验和导出数据——不需要人在不同标签页之间复制粘贴。工作流程通常是这样的：

1. 数据采集：系统从来源读取数据（网页、PDF、图片或表单）。
2. 提取：AI 或 OCR 识别并抓取相关字段。
3. 校验：规则检查错误、重复项或缺失值。
4. 导出：干净的数据流入表格、CRM、ERP 或数据库——通常通过 API 完成。

Thunderbit 在这个流程里扮演的是 AI 驱动的提取层。用 ，业务用户可以打开网页，点击“AI 智能推荐字段”，让 AI 自己判断该提取哪些列——。数据可以直接导出到 Excel、Google 表格、Airtable 或 Notion。对于需要规模化自动化的团队，Thunderbit 的开放 API 又把同样的 AI 变成了可编程端点。

如果你想看自动化数据录入在真实场景里怎么运作，可以看看我们的文章： 或 。

常见问题

1. API 是什么的缩写？

API 是 Application Programming Interface 的缩写，中文是应用程序编程接口。它是一组规则，让两个软件程序能够通信——一个请求数据或动作，另一个以结构化格式回应。

2. 使用 API 需要会写代码吗？

不一定。很多 API 可以通过浏览器、Postman 或像 Zapier 这样的无代码工具来调用。像 Thunderbit 的 Chrome 扩展这样的工具，会在后台使用 API，但你完全不需要写任何代码。开放 API 是可编程的，但业务团队也可以通过内部工具或自动化平台来使用它。

3. API 和网站是一回事吗？

不是。网站是给人读、给人点的；API 是给程序读的——它返回的是结构化数据（比如 JSON），不是可视化网页。它们经常共用同一个域名，但用途完全不同。

4. API 是免费的吗？

有些是免费的（比如公开数据 API）。另一些采用免费增值模式（免费层 + 付费方案），或者按请求收费。比如 Thunderbit 的开放 API 就采用积分制，并提供可测试的免费层。一定要查看每个提供方的定价、速率限制和服务条款。

5. API 密钥和 OAuth 有什么区别？

API 密钥是一串你每次请求都要带上的秘密字符串——简单，适合基础访问。OAuth 2.0 是更复杂的流程，用户会给应用授予有限权限（比如“使用 Google 登录”），这样应用就能访问特定数据，而不会看到用户密码。API 密钥用于识别应用；OAuth 用于授予有范围限制的用户权限。

了解更多