API 实际在系统之间的传递方式
Source: Dev.to
介绍
到目前为止，我们已经讨论了 API 作为系统之间通信的一种方式。
但这里有一个重要的说明。
API 定义了系统之间相互传达的内容。网络协议则定义了这些消息的传输方式。
让我们来讨论几种最常见的消息在网络中传输的方式。
把 API 想象成语言。把协议想象成道路、车辆和交通规则。
HTTP – 基本对话
HTTP 是应用程序在互联网上进行通信的最常用方式。当你打开一个网站或应用加载数据时，通常都会在底层使用 HTTP。
它的工作方式
- 一方发送消息
- 另一方回复
- 对话结束
这就像寄信后等待回复。这种方式非常适用于：
- 加载页面
- 获取数据
- 简单的请求‑响应通信
HTTPS – 带锁的 HTTP
HTTPS 与 HTTP 相同，但已加密。可以把它想象成发送相同的信件，只是放在一个上锁的信封里。只有发送者和接收者能够阅读。
这就是 HTTPS 被用于以下场景的原因：
- 登录系统
- 支付
- 任何敏感数据
从 API 的角度来看，行为没有任何变化。只有隐私和安全性得到了提升。
WebSocket – 保持通话打开
WebSocket 与众不同。它不是发送一条消息后就关闭连接，而是保持线路打开。
这就像一次电话通话：
- 双方保持连接
- 双方随时可以发言
当消息需要双向流动且更新必须即时时，就会使用它。
示例
- 实时聊天
- 实时通知
- 实时仪表盘
使用 WebSocket 的 API 不会“一次又一次地请求”。它们会持续监听。
TCP – 慢速但可靠的传输
TCP 关注可靠性。想象通过快递服务发送易碎物品，该服务：
- 确认送达
- 若有遗失则重新发送
- 保持顺序
这就是 TCP。大多数 API 在底层依赖 TCP，因为：
- 消息能够正确到达
- 不会无声丢失
它比某些选项慢，但值得信赖。
UDP – 快速但无保证
UDP 是相反的做法。它快速发送消息，不检查是否已到达。
想象在房间里大声喊信息：有些人可能会错过，但速度很快。
使用场景：速度比完美更重要
- 视频通话
- 直播流媒体
- 在线游戏
API 很少直接使用 UDP，但基于实时数据的系统常常会使用它。
HTTP/3 (QUIC) – 现代且更快的道路
HTTP/3 是运行在 UDP 之上的新版 HTTP。
概念
- 减少延迟
- 更快地从网络问题中恢复
它适用于：
- 移动应用
- 物联网设备
- 实时体验
从 API 的角度来看，这大多在幕后完成。
SMTP 和 FTP – 专用信使
一些协议专用于非常特定的任务。
- SMTP – 设计用于电子邮件。
- FTP – 设计用于文件传输。
它们不是通用的 API 通信工具，但仍然代表结构化的系统对系统通信，并遵循严格的规则，就像 API 一样。
结论
API 并不是在系统之间神奇漂浮的。它们通过以下协议进行通信：
- HTTP / HTTPS
- WebSocket
- TCP / UDP
- HTTP/3 (QUIC)
- SMTP / FTP
文档会告诉你：
- 使用了哪种协议
- 预期的行为是什么
- 通信是即时的还是延迟的
- 是一次性还是持续的
没有这些明确的信息，团队只能猜测，而猜测会导致系统脆弱。
为什么这对文档很重要
优秀的 API 文档会回答以下问题：
- 我是发起请求还是监听？
- 这是实时的还是延迟的？
- 这安全吗？
- 我会立即得到响应吗？
没有文档，开发者只能随意按按钮，就像在不知道每个按钮功能的情况下使用电视遥控器。
优秀的文档不仅解释 API 本身，还说明如何安全、正确地进行通信。