什么是API？

API（应用程序接口）是一套规则，它使不同的软件能够相互通信。你可以把它想象成一个菜单：你的应用程序可以“点单”数据或操作，而API会准确地告诉“厨房”（即服务端）该“烹饪”什么，以及如何将结果“端上桌”。

API 规范了请求的发送方式和响应的返回方式，因此即使不同系统由不同的团队、公司开发，或使用不同的编程语言编写，也能可靠地协同工作。

从技术实现层面来看，API 定义了端点（可调用的地址）、可用的方法（如用于获取数据的 GET 或用于发送数据的 POST）、数据发送的格式（通常为 JSON），以及应返回的内容（数据以及状态码，例如表示“成功”的 200 或表示“未找到”的 404）。这种可预测性正是 API 的核心所在。

• API：规定了您可以发起哪些请求以及将如何收到响应的契约。
• SDK（软件开发工具包）：一种工具包，通常通过提供现成的代码、示例和实用程序来封装 API，从而简化 API 的使用。
• UI（用户界面）：人们点击和轻触的部分。API 用于软件与软件之间的交互；UI 则是为人们设计的。

严格来说，虽然可以不使用 SDK 直接调用 API，但使用 SDK 既能节省时间，又能减少出错。

是的，有几种风格，每种都有其优缺点：

• REST：当今最常见的Web架构风格。基于资源，使用HTTP方法（GET/POST/PUT/DELETE），通常采用JSON格式。
• GraphQL：客户端可以在单次请求中精确指定所需的字段——这非常有助于减少数据获取过多或过少的情况。
• SOAP：一种基于 XML 的较早协议，具有严格的契约，目前仍被部分企业使用。
• gRPC：一种在微服务中广受欢迎的高性能二进制协议。
• Webhooks：这不是由你发起的请求，而是当发生某些事件时（例如配送通知），服务提供商发回给你的回调。

通常来说，是的。与其自己从头构建所有功能，API 允许你直接集成支付、地图、电子邮件、搜索、分析、人工智能等功能。这不仅能节省工程开发时间、提高可靠性（服务提供商会持续更新其服务），还能让你的团队专注于打造产品的独特之处。

权衡之处：你会继承自服务提供商的调用频率限制、定价以及正常运行时间的依赖关系。如果你的产品离不开该 API，请规划好冗余方案。

经常如此。许多 API 都需要身份验证，以便提供商识别您的身份，并据此授予权限和实施速率限制。常见的方法包括：

• API密钥：您在每次请求中随附的简单令牌。
• OAuth：一种更安全的委托式方法，在需要代表用户访问时非常适用。
• 签名请求/JWT：经过加密签名的令牌，具有有效期，并可携带声明（即你的身份以及你被允许执行的操作）。

尽可能不要将密钥和令牌放在公共仓库和客户端代码中。

其实不然。对于许多 API 来说，网页浏览器、curl 或任何 HTTP 客户端都能胜任。开发人员通常会使用 Postman 之类的工具或语言内置库来发送请求、检查响应并保存示例。对于生产环境中的应用程序，则需要使用所用编程语言的 HTTP 库或服务提供商的 SDK。

几乎所有现代应用都离不开它：移动应用调取用户资料、“通过 Google/Apple 登录”、网店处理支付、智能家居设备同步、仪表盘调取分析数据，甚至你的天气小工具也是如此。只要软件在交换数据，背后很可能就有一套 API 在运作。

• 端点：您调用的 URL（例如，/users/123）。
• 请求/响应：你发送的内容与收到的内容。
• 有效载荷/正文：请求或响应中的数据。
• 状态码：数值结果（200 OK、201 已创建、401 未授权、429 请求过多、500 服务器错误）。
• 请求限制：在某个时间段内可以发出的请求数量。
• 版本控制：将新旧 API 的行为区分开来（例如，/v1/ 与 /v2/）。
• 幂等性：多次执行同一请求会得到相同的结果（例如 GET）。