退休定义的Thrift API的最佳实践？

Question

只是好奇在下面的情况会发生什么？

1. 定义的API在最新的节俭服务定义中被删除;
2. 在服务器端的升级将实施最新的定义（即没有关于删除的API的更多实现）;
3. 有些客户可能仍停留在过时的服务定义和有流量被删除的API。

作为一个更普遍的问题，是否有任何最好的实践来退休现有的API（即，一旦在.thrift文件中定义）？

Answer 1

这就是软的版本，这是不是一个唯一的节俭功能的好处之一。随着时间的推移，API可能会发生变化，并且只要某些非常少量的规则得到遵守，就会有一个定义明确的应用程序行为方式。

关于节俭这些规则包括一个应该永远不会改变任何给定的结构构件或参数的特定字段ID的类型。服务名称和方法名称也是如此。数字字段/参数ID和服务/方法名称是线路数据中使用的标识符。

因此，

• 如果一个场/参数变化类型，数字ID也应改变
• 字段和方法已被弃用应被注释，而不是从IDL除去（至防止它们后来被重用）

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

否则你会在老客户在呼唤新的服务，反之亦然碰上compat的问题。