18、常见 API 范式与 Craigslist 系统设计解析

常见 API 范式与 Craigslist 系统设计解析

1. 库与服务的权衡及其他考量

在开发过程中，对于库的扩展有不同的方式。若要通过使用该库的应用程序来扩展库，用户可以创建一个围绕该库的服务包装器并扩展该服务。但这样一来，它就不再是一个库，而是用户拥有的服务，扩展成本由用户承担。

此外，还有一些其他需要考虑的因素：
- 工程师的心理顾虑 ：部分工程师在将代码与库捆绑时会有心理顾虑，但愿意连接服务。他们担心库会增加构建大小，特别是 JavaScript 捆绑包，还担心库中存在恶意代码。而服务则不存在这些问题，因为工程师可以控制发送到服务的数据，并能完全了解服务的响应。
- 对变更的容忍度 ：人们通常预期库会有重大变更，但对服务（尤其是内部服务）的重大变更容忍度较低。服务开发者可能不得不采用笨拙的 API 端点命名约定，如在端点名称中包含“/v2”“/v3”等。
- 设计模式的使用频率 ：有证据表明，使用库时比使用服务时更常遵循适配器模式。

2. 常见 API 范式

常见的通信范式有 REST、RPC、GraphQL 和 WebSocket，在为服务选择范式时，需要考虑它们之间的权衡。

2.1 OSI 模型

7 层 OSI 模型是一个概念框架，用于描述网络系统的功能，而不考虑其底层内部结构和技术。各层的简要描述如下表所示：
| 层编号 | 名称 | 描述 | 示例 |
| ---- | ---- | ---- | ---- |
| 7 |