15、数据编码、传输与分布式系统架构解析

数据编码、传输与分布式系统架构解析

1. RPC 与 REST API 的数据编码及兼容性

在 API 设计领域，REST 风格在公共 API 中占据主导地位，而 RPC 框架主要用于同一组织内服务间的请求交互，通常在同一数据中心内进行。

对于 RPC 而言，实现可演化性的关键在于客户端和服务器能够独立更改和部署。在服务间的数据流动中，可做简化假设：先更新所有服务器，再更新所有客户端。所以，请求只需具备向后兼容性，响应则需具备向前兼容性。

RPC 方案的前后兼容性继承自其所采用的编码方式：
| 编码方式 | 兼容性情况 |
| ---- | ---- |
| Thrift、gRPC（Protocol Buffers）、Avro RPC | 可根据各自编码格式的兼容性规则进行演化 |
| SOAP | 请求和响应通过 XML 模式指定，虽可演化，但存在一些微妙的陷阱 |
| RESTful APIs | 响应常用 JSON（无正式指定模式），请求使用 JSON 或 URI 编码/表单编码的请求参数。添加可选请求参数和向响应对象添加新字段通常被视为保持兼容性的更改 |

由于 RPC 常跨越组织边界进行通信，服务提供者往往无法控制客户端，也不能强制其升级，因此需长期甚至无限期保持兼容性。若必须进行破坏兼容性的更改，服务提供者通常需同时维护服务 API 的多个版本。

目前，API 版本控制尚无统一标准。对于 RESTful APIs，常见做法是在 URL 或 HTTP Accept 头中使用版本号。对于使用 API 密钥识别特定客户端的服务，另一种选择是在服务器上存储客户端请求的 API 版本，并允