退出定义的Thrift API的最佳做法？

Question

对下面的情景会发生什么感到好奇？

1. 在最新的thrift服务定义中删除已定义的API;
2. 服务器端的实现升级到最新定义（即，没有关于已移除的API的实现）;
3. 某些客户端可能仍会保留过时的服务定义，并且会为已删除的API提供流量。

作为一个更普遍的问题，退出现有API（即曾经在.thrift文件中定义）是否有最佳实用性？

Answer 1

这是软版本控制的好处之一，它不仅仅是Thrift功能。 API可能会随着时间的推移而发生变化，只要遵守一套非常极小的规则，就会有一种定义明确的应用程序行为方式。

关于Thrift，这些规则包括永远不应该改变任何给定struct成员或参数的特定字段ID的类型。服务名称和方法名称也是如此。数字字段/参数ID和服务/方法名称是电线上数据中使用的标识符。

因此，

• 如果字段/参数的类型发生更改，则还应更改数字ID
• 已弃用的字段和方法应进行注释，而不是从IDL中删除（以防止以后再次使用）

值得一提的最后一点是关于required的使用：此属性可能无法从已发布的API结构成员because of the way of how the required semantics work中删除。

否则，当旧客户端调用新服务时，您将遇到compat问题，反之亦然。